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PREFACE 


This  report  documents  the  first  technical  effort  associated  with  the  Armstrong  Laboratory, 
Logistics  Research  Division's  (AL/HRG)  Enhanced  Contingency  Logistics  Planning  and  Support 
Environment  (ECLiPSE)  research  and  development  (R&D)  initiative.  The  goal  of  this  initiative  is  to 
demonstrate  how  advanced  technologies  can  improve  the  quality  and  timeliness  of  wing  Ic^istics 
planning  and  replanning  for  short-notice  contingency  operations.  The  goal  of  this  effort  was  to 
develop  preliminary  concept  specifications  for  the  operational  components  and  relevant  information 
technologies  for  a  notional  "ECLiPSE  system." 

AL/HRG  intends  to  use  the  results  of  this  effort  as  a  starting  point  for  fixture  investigations 
and  demonstrations  in  this  area.  The  ECLiPSE  vision  documented  in  this  report  is  not  final;  as  users 
get  more  involved  in  defining  ECLiPSE,  the  specifications  will  evolve  based  on  their  feedback.  This 
report  serves  three  functions:  (1)  document  the  effort,  (2)  guide  AL/HRG  and  other  Department  of 
Defense  investment  in  research  in  this  important  area,  and  (3)  communicate  the  preliminary  ECLiPSE 
vision  to  AL/HRG's  Air  Force  (AF)  customers. 

Throughout  the  study,  the  authors  depended  on  the  cooperation  of  many  Air  Force 
personnel.  Numerous  logisticians  and  maintainers  from  the  366th  Wing,  52nd  Wing,  36th  Fighter 
Wing,  and  the  906th  Fighter  Group  gave  their  time  to  explain  the  intricacies  and  problems  associated 
with  AF  logistics  planning  processes.  Various  headquarters  and  agency  personnel  were  also  vital  to 
the  effort.  LtCol  Burleson,  Capt  Leflwich,  and  Mr.  Newhouse  from  Air  Staff;  LtCol  Butz  and  Capt 
Jennings  from  the  Air  Force  Logistics  Management  Agency  (AFLMA);  Maj  Moore  from  AF  Special 
Operations  Command  (AFSGC);  Capt  Gage,  Capt  Miyares,  MSgt  Steffee,  and  TSgt  Sherman  from 
Air  Combat  Command  (ACC);  and  Maj  Edwards,  Capt  Talley,  and  Mr.  Demaree  from  the  Standard 
Systems  Center  (SSC)  contributed  by  providing  information  on  upgrades  to  current  systems  and  new 
systems  under  development,  by  verifying  our  conclusions,  and  by  providing  feedback  on  our  initial 
attempts  to  define  the  ECLiPSE  vision. 

The  authors  also  extend  their  thanks  to  AL/HRG  management  and  personnel  fiar  their 
support  and  patience  throughout  the  study  effort.  Mr.  Cream,  Mr.  Johnson,  and  LtCol  Smoot 
reviewed  the  results  of  the  study  on  more  than  one  occasion  —  each  time  providing  critical  insight. 
Capt  Gwartney  provided  numerous  "sanity  checks"  throughout  the  effort.  ILt  Carrico  helped  the 
authors  synthesize  and  integrate  information  on  the  relevant  technologies.  Together,  the 
contributions  fi'om  AL/HRG  personnel  were  essential  to  the  successfiil  completion  of  this  important 
R&D  effort. 
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THE  ENHANCED  CONTINGENCY  LOGISTICS  PLANNING  AND  SUPPORT 

ENVIRONMENT:  THE  VISION 

SUMMARY 

This  report  documents  the  results  of  Task  #33  of  the  Supportability  Investment 
Decision  Analysis  Center  (SID AC)  contract.  The  effort,  entitled  "Enhanced  Contingency 
Logistics  Planning  Support  Environment  (ECLIPSE),"  was  sponsored  by  the  United 
States  Air  Force  (USAF)  Armstrong  Laboratory,  Logistics  Research  Division,  Wright- 
Patterson  AFB,  Ohio.  The  Analytic  Sciences  Corporation  (TASC)  located  in  Fairborn, 
Ohio,  performed  the  majority  of  the  work. 

The  primary  goal  of  Task  #33  was  to  study  the  logistics  planning  process  in  order 
to  identify  how  state-of-the-art  software  technologies  can  improve  wing  logistics  planning 
in  short-notice  crisis  situations.  More  specifically,  the  study  team  examined  the  Air  Force 
(AF)  wing  logistics  planning/replanning  process  and  the  software  tools  that  support  it  to 
conceptualize  the  ECLIPSE  vision.  The  vision  was  formulated  to  guide  laboratory 
investment  aimed  at  improving  AF  wings'  capabilities  to  plan  and  replan  for  short-notice 
taskings.  This  report  describes:  (1)  the  current  and  planned  wing  logistics  planning 
environment,  (2)  the  components  comprised  by  the  preliminary  ECLIPSE  vision,  and  (3) 
the  current  state  of  the  relevant  technologies  as  they  apply  to  the  ECLIPSE  system. 


INTRODUCTION 

Today's  wing  logistics  planners  rely  on  many  sources  of  information  and  a  m5aiad 
of  supporting  computer  systems  to  help  determine  the  resources  and  manpower  to  deploy 
in  crisis  situations.  Reviews  of  the  utility  of  these  information  sources  and  the 
effectiveness  of  currently  used  software  systems  conducted  in  the  aftermath  of  Desert 
Shield/Storm  identified  numerous  problems.^  To  a  large  degree,  the  AF  is  addressing  these 
problems  by  fielding  a  suite  of  new,  integrated  software  systems.^  Unfortunately,  these 
programs  will  not  solve  all  the  current  problems  and,  more  importantly  to  this  research 
and  development  (R&D)  initiative,  do  not  address  some  of  the  fundamental  shortcomings 
of  the  current  planning  process.  The  ECLIPSE  vision  was  formulated  to  guide  laboratory 


The  most  beneficial  sources  used  to  make  these  conclusions  were:  (1)  the  USAF  Joint  Unit  Lessons 
Learned  database  (particularly  logistics  plans  lessons  learned),  (2)  Air  Force  Logistics  Management 
Agency  reports,  and  most  importantly  (3)  the  study  team's  interviews  with  wing  and  headquarters  level 
personnel. 

^he  AF  is  upgrading  many  logistics  planning  systems  and  integrating  them  under  an  initiative  called  the 
Integrated  Deployment  System  (IDS).  One  component  of  IDS  is  a  new  system,  being  developed  by  the  Air 
Force  Logistics  Management  Agency  (AFLMA),  called  the  Automated  Mobility  Planning  Systran 
(AMPS).  The  AF  is  also  creating  the  foundation  for  a  standard,  integrated  wing  information  system 
through  the  Wing  CJommand  and  Control  System  (WCCS)  program.  Each  of  these  initiatives  is  discussed 
in  more  detail  in  Section  IV. 
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research  aimed  at  addressing  the  fundamental  shortcomings  that  result  from  technology 
limitations. 

The  current  ECLiPSE  vision  assumes  that  future  wings  will  have  a  network 
infrastructure  and  an  operating  environment  based  on  the  Open  System  Environment 
(OSE)  standard.  These  assumptions  are  consistent  with  the  direction  being  taken  by  the 
industry  and  with  AF  plans  to  develop  new  systems  and  upgrade  current  wing  logistics 
planning  systems  (Standard  Systems  Center,  1994b).  These  assumptions  will  allow 
components  of  ECLiPSE  to  be  developed  as  separate  modules  with  limited  interfaces  to 
existing  and  planned  systems.  The  current  ECLiPSE  vision  is  an  integration  of  three 
projects.  Each  project  concept  was  driven  by  the  desire  of  AF  planners  for  a  more 
accurate,  timely,  and  flexible  wing  logistics  planning  capability.^ 

The  first  ECLiPSE  project  is  the  Deployment  Information  and  Support 
Environment  (DISE).  DISE  is  composed  of  two  parts.  The  first  is  a  centrally  located 
information  system  called  the  Deployment  Knowledge  Base  (DKB).  The  DKB  will 
provide  fast  access  to  in-depth  audio,  visual,  and  textual  information  pertaining  to 
potential  deployment  sites  (for  readers  familiar  with  the  current  airfield  information 
system,  think  of  the  DKB  as  the  next  generation  airfield  information  source).  The  types  of 
information  stored  in  the  DKB  include  site  specific  maps,  site-  and  region-specific  lessons 
learned,  airbase  infrastructure  information,  and  information  on  local  suppliers  of  off-the- 
shelf  resources.  The  goal  of  the  DKB  portion  of  ECLIPSE  is  to  provide  all  wing  planners 
with  immediate  access  to  near  real-time  information  about  the  specific  sites  to  which  their 
units  might  possibly  be  deployed.  The  second  part  of  DISE  is  the  DKB's  input  and  user 
interface  mechanisms.  An  automatic  lessons-leamed  recording  system  (ALLRS)  and  a 
multimedia  airbase  information  collection  tool  (Multimedia  Air  Field  Information  System 
(MAFIS))  constitute  the  primary  input  mechanisms  for  the  DKB.  Conceptually,  the  DKB 
vwll  be  distributed  and  available  to  every  Air  Force  unit  through  satellite  links  and  wide 
area  networks.  Users  will  have  the  capability  to  query  and  edit  the  DKB  from  both 
remote  and  home  stations. 

The  second  ECLiPSE  project  is  the  Unit  Type  Code  Development,  Tailoring,  and 
Optimization  (UTC-DTO)  tool.  UTC-DTO  is  composed  of  two  subcomponents;  (1)  an 
automatic  UTC  development  and  tailoring  capability  and  (2)  an  automatic  palletization 
optimization  system.  The  development  and  tailoring  part  of  this  component  will 
automatically  generate  or  tailor  UTCs  for  a  specific  mission.  During  a  crisis,  this 
component  will  automatically  highlight  all  the  items  in  the  tasked  UTC  that  need  to  be 
tailored  into  or  out  of  the  package.  UTC-DTO  will  use  information  stored  in  the  DKB, 
along  with  other  important  pieces  of  information,  as  inputs  to  the  automatic  tailoring 
process.  The  optinuzation  part  of  this  component  will  automatically  generate  near-optimal 
pallet  arrangements  based  on  the  tailored  UTCs. 


^The  "desires  of  planners"  were  determined  through  an  extensive  literature  search  that  focused  on  AF 
logistics  planning  problems  and  numerous  interviews  with  both  operational  and  headquarters  persoimel. 
The  literature  search  and  the  interview  methodology  and  results  are  described  in  Section  III  and  Section 
IV,  respectively. 
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The  third  ECLiPSE  project  is  the  Logistics  Analysis  to  Improve  Deployability 
(LOG-AID).  LOG-AID  will  rigorously  analyze  the  mobility  and  deployment  process  at 
the  wing  and  unit  level  from  receipt  of  a  Time  Phased  Force  Deployment  Listing  (TPFDL) 
until  the  associated  cargo  and  personnel  are  packed,  prepared,  and  ready  to  board  a 
conveyance  to  the  mission  area.  It  also  recommends  innovative  processes  and 
technologies  to  improve  the  current  process. 

Each  component  will  leverage  state-of-the-art  information  technologies  such  as 
distributed  computer-based  audio  and  visual  communications,  artificial  intelligence  (AI) 
and  decision  support  techniques,  multimedia,  distributed  data  management,  advanced 
simulation  techniques,  and  object-oriented  design  methodologies.  For  example,  AI 
techniques  will  be  very  useful  in  the  development  of  UTC-DTO.  Distributed  multi-media 
data  management  will  be  very  useful  in  the  development  of  the  DKB.  Together,  these 
technologies  can  significantly  enhance  wing  logistics  planning  in  crisis  situations. 

The  three  integrated  projects  of  the  ECLiPSE  vision  will  lead  to  a  broader 
program  called  Total  ECLiPSE.  Total  ECLiPSE  will  bring  together  everything  learned 
from  ECLiPSE  and  its  three  projects  (DISE,  LOG-AID,  and  UTC-DTO)  into  a  total 
deployment  concept  for  fiiture  deployments.  The  goal  of  Total  ECLiPSE  is  to  use  a 
fighter  wing  as  the  test  base  for  a  totally  re-engineered  deployment  process. 


METHODOLOGY 

In  formulating  the  ECLiPSE  vision,  the  study  team  (made  up  of  AL/HRG  and 
TASC  personnel)  focused  on:  (1)  wing  and  unit  logistics  planning,  (2)  crisis  planning  and 
replanning  (as  opposed  to  deliberate  planning),  and  (3)  long-range  technology  solutions  to 
logistics  planning  problems.  The  primary  reason  the  study  team  focused  on  wing  logistics 
planning  as  opposed  to  other  "levels"  of  planning  is  that  AF  and  Department  of  Defense 
(DoD)  research  organizations  are  already  highly  involved  in  developing  and  demonstrating 
information  technologies  for  theater  command  and  Joint  Task  Force  (JTF)  level  logistics 
planning. 

In  formulating  the  ECLiPSE  vision,  AL/HRG  and  TASC  researchers  first  carried 
out  an  extensive  literature  review  that  focused  on  identifying  wing  logistics  planning 
problem  areas.  In  general,  the  literature  review  highlighted  contingency  planning 
problems  related  to  the  reliability  and  level  of  integration  of  current  planning  systems,  the 
accuracy  and  availability  of  needed  information,  and  the  amount  of  time  necessary  to 
accurately  plan  and  replan  for  short-notice  taskings. 

In  addition  to  reviewing  documents,  the  study  team  discussed  deployment  planmng 
problems  with  personnel  from  numerous  operational  AF  units,  headquarters  organizations, 
and  the  AF  Logistics  Management  Agency  (AFLMA).  The  purpose  of  these  discussions 
was  to  verify  and  clarify  the  problem  areas  highlighted  during  the  literature  search.  The 
organizations  that  were  contacted  for  this  purpose  are: 
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•  366th  Wing  (Mt.AFB), 

•  52nd  Wing  (Spangdahlem  AFB), 

•  36th  Fighter  Wing  (Bitburg  AFB), 

•  906th  Fighter  Group  (Wright-Patterson  AFB), 

•  HQ  ACC/LGX, 

®  HQ  AFSOC/LGX, 

•  HQ  USAF/LGX,  and 

•  AFLMA/LGX. 

The  study  team  also  collected  information  on  initiatives  that  are  addressing  many 
of  the  problems  experienced  during  Desert  Shield/Storm.  The  literature  review  conducted 
to  investigate  logistics  planning  problems  was  very  useful  for  this  task  because  it  revealed 
numerous  systems  currently  in  use  or  under  development.  Armed  with  knowledge  of 
these  systems,  the  study  team  interviewed  developers,  users,  and  maintainers  of  these 
systems  in  order  to  gain  a  greater  appreciation  for  the  systems'  current  utility  and,  more 
importantly,  the  systems'  future  in  AF  wing  logistics  planning.  The  systems  investigated  in 
this  manner  are: 

•  Integrated  Deployment  System  (IDS), 

•  Wing  Command  &  Control  System  (WCCS), 

•  Contingency  Operation  Mobility  Planning  &  Execution  System  (COMPES), 

•  Combat  Readiness  &  Infrastructure  Support  Information  System  (CRISIS), 

•  Automated  Mobility  Planning  System  (AMPS), 

•  Computer-Aided  Load  Manifesting  (CALM)  System,  and 

•  Cargo  Movement  &  Operation  System  (CMOS). 

Based  on  the  problems  found  in  wing-level  logistics  planning,  the  study  team  set 
out  to  develop  the  ECLIPSE  vision.  The  team  first  reviewed  literature  to  determine  the 
current  state  of  the  art  for  a  wide  variety  of  information  technologies,  including  distributed 
computer-based  audio  and  visual  communications,  AI  and  decision  support  techniques, 
multimedia  distributed  data  management,  advanced  simulation  techniques,  and  object- 
oriented  design  methodologies.  The  ECLiPSE  vision  was  then  developed  through  a  series 
of  brainstorming  sessions  with  technologists  and  representatives  from  SSC,  AFLMA,  Air 
Staff,  ACC,  and  AFSOC.‘‘ 
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Air  Mobility  Command  (AMC)  did  not  participate  in  any  of  the  brainstorming  sessions.  This  was  the 
result  of  time/budget  constraints  and  the  authors'  focus  on  combat  unit  deployment  planning  and 
replanning.  (At  the  time  this  report  was  being  drafted,  AL/HRG  was  in  the  process  of  establishing  a 
dialogue  with  HQ  AMC/LGX.) 
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DATA  ANALYSIS 


After  talking  to  many  logisticians  and  reviewing  regulations,  specifications  on  new 
and  existing  systems,  journal  articles,  and  lessons  learned  reports  (from  Desert 
Shield/Storm),  the  study  team  developed  an  understanding  of  the  current  wing  planning 
environment.  The  following  sections  briefly  explain  the  current  wing-level  deployment 
planning  environment  and  discuss  several  problem  areas  that  are  the  impetus  for  ECLiPSE 
research. 


Current  Wing  Logistics  Planning  Environment 

As  previously  stated,  the  study  team  focused  on  the  wing  logistics 
planning/replanning  process  for  short-notice,  crisis  situations.  This  section  introduces  the 
wing  deployment  planning  and  replanning  process  by  (1)  introducing  the  types  of 
information  used,  (2)  discussing  the  computerized  information  systems  that  support  the 
process,  and  (3)  summarizing  the  general  problems  that  were  identified  during  the  study. 
The  aim  is  not  to  provide  a  detailed  or  complete  description  of  the  process;  other 
documents  do  this  (e.g.,  AFR  28-3,  AFR  28-4,  AFR  28-6,  etc.).  Instead,  the  aim  is  to 
explain  the  study  team's  view  of  the  wing  logistics  planning  process.  This  section  is 
important  because  it  describes  the  "view"  used  to  formulate  the  ECLiPSE  vision. 

Logistics  Planning  Information 

Wing  personnel  require  a  wide  variety  of  information  in  order  to  quickly  and 
accurately  plan  and  replan  for  short-notice  taskings.  Five  important  types  of  information 
are  (1)  expected  length  and  pace  of  operations,  (2)  other  units  that  are  deploying  to  the 
same  location,  (3)  beddown  location  attributes,  (4)  maximum  manpower  and  material  that 
can  be  deployed,  and  (5)  t5q)e  and  amount  of  airlift  allocated  to  the  unit.  Each  t5q)e  of 
information  is  discussed  below. 

Expected  length  and  pace  of  operations 

The  manpower  and  materiel  required  to  support  a  unit's  part  of  the  Operational 
Plan(OPLAlSl)  may  be  significantly  affected  by  the  length  of  the  deployment  and  the  pace 
of  the  deployment  operations.  Most  subjects  interviewed  assumed  that  higher  sortie 
generation  rates  would  require  more  materiel  and  personnel.  Typically,  longer  sortie 
durations  were  also  assumed  to  increase  materiel  requirements,  but  actual  Desert 
Shield/Storm  data  contradicts  that  assumption.  Discussions  with  HQ  USAF/LGS 
indicated  that  many  projections  of  spares  usage  were  three  to  four  times  greater  than 
actual  requirements.  While  this  outcome  was  viewed  as  being  better  than  having 
insufficient  in-theater  spares,  clearly  there  is  potential  for  more  effective  use  of  mrlift. 
Obviously,  if  aircraft  are  not  hauling  unneeded  spares,  they  can  be  tasked  to  haul 
additional  combat  capability. 

The  model  used  for  equipment  projections  was  the  Dynametric  model,  which  is 
also  used  for  the  equipment  capability  portion  of  the  Status  of  Resources  and  Training 
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System  (SORTS)  reports  (AFR  55-15).  According  to  HQ  ACC/LGS,  the  Dynametric 
model  tends  to  project  a  linear  increase  in  required  numbers  of  spare  parts  with  increasing 
sortie  duration.  In  practice,  this  is  typically  a  poor  assumption  because  many  failures 
(especially  avionics  failures)  are  associated  more  with  power  cycling  or  ground  operations 
rather  than  with  a  longer  cycle.  Algorithms  for  the  Dynametric  model  were  already  being 
analyzed  for  modification  during  this  study,  and  a  more  realistic  projection  capability  will 
probably  exist  in  the  Dynametric  version  that  will  be  available  by  the  time  this  report  is 
published. 

In  addition  to  the  spares-projection  errors  caused  by  the  assumption  that  lon^ 
sortie  durations  equate  to  higher  spares  usage,  Dynametric  may  project  incorrect 
quantities  based  on  failure  rate  data  input  to  the  model.  According  to  HQ  USAF/LGS, 
fleet-wide  data  is  used  for  failure  rates.  When  significant  quantities  of  aircraft  exist  at 
locations  approximating  the  climate  and  conditions  of  the  deployment  location,  it  would 
be  beneficial  to  take  the  appropriate  "slice"  of  the  fleet- wide  failure  rate  data  to  obtain 
specific  failure  projections  for  the  area  of  interest.  Another  potential  reason  for  the 
number  of  bad  projections  on  spares  requirements  is  the  use  of  standard  planning  factors 
from  the  War  Mobilization  Plan,  Volume  5  (WMP-5)  for  sortie  length  and  duration  for 
different  aircraft  types.  The  implication  is  that  these  factors  are  based  on  a  European 
scenario  that  does  not  correspond  entirely  with  the  situation  in  the  Gulf,  according  to  HQ 
USAF/LGS  and  HQ  ACC/LGS. 

Units  Deploying  to  the  Same  Operating  Location 

Associated  with  each  OPLAN  for  anticipated  force  employment  is  a  Time-Phased 
Force  Deployment  Document  (TPFDD)  file.  Its  contents  are  typically  seen  at  the  unit 
level  in  the  form  of  a  list,  the  TPFDL,  which  contains  information  on  (1)  in-place  units;  (2) 
units  to  be  deployed  and  their  order  of  deployment  and  port  of  debarkation;  (3)  routing  of 
forces  being  deployed;  (4)  non-unit-related  cargo  and  personnel  movements;  and  (5) 
transportation  requirements  for  common-user  lift  and  organization-owned  transportation 
resources.  The  TPFDL  provides  a  list  of  all  units  deployed  to  different  geographic 
locations  (GEOLOCs)  witWn  the  OPLAN,  and  the  Unit  Type  Codes  (UTCs)  expected  to 
be  deployed  (Patrick  et  al,  1989).  By  knowing  which  other  units  will  be  at  the  same 
location,  a  unit  can  coordinate  to  share  common  resources  and  avoid  airlifting  redundant 
equipment.  Time-phasing  units  provides  wing  planners  with  dates  that  must  be  met  to 
successfully  implement  the  deployment  portion  of  the  OPLAN.  These  dates  form  the  basis 
for  the  entire  deployment  process. 

Beddown  Location  Attributes 

Several  different  sources  are  typically  accessed  to  obtain  information  on  the 
deployed  location.  These  include  the  Automated  Air  Field  Information  File  (AAFIF), 
reports  from  advanced  deployment  teams,  and  detailed  site  surveys.  This  information  can 
be  used  by  the  deploying  unit  to  help  tailor  UTCs  to  meet  specific  needs  at  specific 
locations.  If  local  sources  can  be  obtained  for  fuel,  transportation,  aircraft  loading,  and  so 
forth,  significant  reduction  in  airlift  is  possible.  Other  factors  might  significantly  change 
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the  order  in  which  elements  are  shipped.  For  example,  reports  of  terrorist  activity  might 
result  in  a  decision  to  transport  additional  security  police  in  the  initial  phase  of  the 
deployment.  Reported  conditions  of  runways,  parking  areas,  hangars,  dormitories,  and 
the  like,  could  affect  the  tailoring  of  UTCs  as  well. 

Maximum  Manpower  and  Material  that  can  be  Deployed 

The  basic  Air  Force  document  controlling  deployment  is  the  UTC.  Everything  that 
is  initially  deployed  with  a  unit  is  listed  in  the  UTC.  UTCs  are  listed  in  the  TPFDD  as 
five-character  identifiers  that  uniquely  specify  a  force  or  support  package.  Along  with  the 
UTC,  a  completed  TPFDD  lists  a  specific  unit,  the  Unit  Identification  Code  (UIC),  tasked 
to  fill  the  UTC  requirement.  The  majority  of  the  UTC  consists  of  the  manpower/logistics 
detail,  contained  in  the  manpower  force  element  listing  (MFEL)  and  the  logistics  detail 
(LOGDET).  The  MFEL  is  broken  down  by  Air  Force  Specialty  Code  (AFSC)  type  and 
quantity  of  personnel,  and  a  code  specifying  where  each  person  will  be  working.  The 
LOGDET  specifies  a  list  of  all  the  equipment  needed,  including  weight,  size,  shipping 
characteristics,  national  stock  numbers,  and  the  increment  number  for  each  item.  The 
increment  number  specifies  the  order  in  which  the  equipment  is  transported;  typically,  each 
increment  is  a  pallet  of  material  or  a  piece  of  wheeled  equipment  (Aerospace  Ground 
Equipment,  vehicle,  etc.)  (Patrick,  1989). 

Standard  UTCs  are  developed  by  “pilot”  units  as  benchmarks  for  other  units.  A 
pilot  unit  is  a  unit  tasked  to  develop  a  standard  UTC  for  use  by  all  units  equipped  with  a 
specific  weapon  system.  The  pilot  unit  acts  as  a  single  point  of  contact  for  development 
and  maintenance  of  a  standard  UTC.  Pilot  units  report  the  LOGDET  data  to  the  Major 
Command  (MAJCOM)  for  inclusion  or  update  of  the  MAJCOM  logistics  force  packaging 
subsystem  called  LOGFOR.  When  a  unit  is  tasked  to  deploy  a  UTC,  it  may  deploy  the 
standard  UTC  or  a  tailored  UTC.  The  process  of  tailoring  the  UTC  from  the  standard 
UTC  is  done  at  the  unit  level  and  involves  consideration  of  specific  deployment 
conditions.  Creation  of  the  standard  UTCs,  as  well  as  tailored  UTCs,  is  a  labor-intensive 
process,  vnth  little  help  from  automated  tools.  At  the  366th  Wing  at  Mountain  Home 
AFB,  construction  of  the  standard  force  packages  for  a  combined  wing  structure  was 
accomplished  by  manually  listing  the  required  equipment  and  personnel  on  white  boards 
on  all  walls  of  a  large  conference  room.  Tailored  UTCs  are  based  on  assumptions  of 
where  they  will  be  deployed,  which  is  given  in  the  OPLAN.  Short-notice  deployments  in 
the  future  may  necessitate  much  faster  tailoring  UTCs,  using  the  one  that  most  closely  fits 
the  anticipated  situation. 


Type  of  Airlift  Allocated 

Each  unit  needs  to  load  plan  its  UTCs  based  on  the  type  of  aircraft  it  will  be  using 
for  transport.  Load  planning  involves  deciding  how  equipment  will  be  palletized  and  how 
the  pallets  will  be  loaded  on  the  particular  aircraft  while  maintaining  aircraft  center-of- 
gravity  requirements. 


7 


Supporting  Systems 


In  addition  to  focusing  on  the  types  of  logistics  planning  information,  the  study 
team  analyzed  current  and  future  logistics  planning  systems  and  tools.  There  are  many 
systems  being  used,  current  systems  being  upgraded,  and  new  systems  being  developed. 
The  study  team  focused  on  this  area  for  three  reasons:  (1)  to  identify  problems  associated 
\^dth  the  current  systems,  (2)  to  understand  what  problems  the  new  and  upgraded  systems 
were  addressing,  and  (3)  to  ensure  that  the  ECLiPSE  Vision  is  compatible  with  the  AF's 
plaimed  wing-level  operating  environment. 

The  primary  AF  logistics  planning  system  COMPES,  governed  by  APR  28-6. 
COMPES  has  base-  and  MAJCOM-level  components.  It  also  interfaces  with  the  Joint 
Operation  Planning  and  Execution  System  (JOPES).  Although  COMPES'  components 
and  interfaces  are  complex,  the  base-level  portion  of  the  system,  comprised  of  LOGMOD- 
B  and  MANPER-B,  is  relatively  simple  to  understand.  LOGMOD-B's  primary  function  is 
to  allow  units  to  retrieve,  store,  and  edit  the  equipment  associated  with  UTCs.  It  answers 
the  critical  question,  "What  do  we  take  on  this  deployment?"  MANPER-B  provides  a 
similar  capability  for  planning  personnel  deployments.  It  answers  the  question,  "What 
type  and  how  many  people  need  to  deploy?" 

Although  COMPES  is  the  official  AF  wing  logistics  planning  system,  wings  also 
rely  on  many  other  systems  for  planning  and  executing  deployments.  These  systems, 
along  with  a  suite  of  new/upgraded  systems,  are  being  integrated  under  an  initiative  called 
the  Integrated  Deployment  System  (IDS).  Additional  new  systems  like  the  Global 
Command  and  Control  System  (GCCS  which  is  replacing  the  World-Wide  Military 
Command  and  Control  System  (WWMCCS)),  the  WCCS,  and  CRISIS  will  play  important 
roles  in  the  future  wing  logistics  planning  process. 

An  important  feature  common  to  all  upgraded  and  new  systems,  is  that  they  are 
being  developed  using  the  "open  systems"  approach.  Thus,  the  new/upgraded  applications 
will  be  more  flexible,  portable  across  different  platforms,  and  capable  of  operating  on 
networks  comprised  of  varied  computer  hardware  and  software  applications.*  This  is 
relevant  because  the  future  wing  computing  environment  (being  defined  by  these 
ongoing  programs)  will  allow  ECLiPSE  components  to  seamlessly  interface  in  the 
same  environment. 

The  paragraphs  below  briefly  introduce  the  systems  that  will  define  the 
environment  in  which  ECLiPSE  will  operate.  The  aim  is  twofold:  (1)  to  introduce  the 
uninitiated  reader  to  these  systems  and  provide  references  for  more  detailed  information, 
and  (2)  to  discuss  the  systems'  importance  to  the  ECLiPSE  Vision.  Current  and  upgraded 


*The  term  "open  systems"  refers  to  a  federal  government  standards  initiative  and  the  general  industry 
software  development  trend.  In  current  practice,  the  "open  systems  approach"  means:  (1)  the  Unix 
operating  system,  (2)  X  Windows,  (3)  Structured  Query  Language  (SQL),  the  Initial  Graphics  Exchange 
Specification  (IGES),  the  Graphical  Kernel  System  (GKS),  and  other  software  development  standards. 
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systems  are  discussed  as  components  of  IDS.  WCCS  and  CRISIS  are  discussed  as 
separate  systems. 

Integrated  Deployment  System  (IDS) 

IDS  is  the  integration  of  several  base-level  automated  systems,  some  of  which  are 
upgraded  systems  and  some  of  which  are  new.  These  include  the  LOGMOD^ 
Modernization,  AMPS,  MANPER-B,  CMOS,  and  CALM. 

COMPES  and  LOGMOD-B.  Although  contingency  planning  has  been  done  at  the 
unit  level  in  some  fashion  since  the  formation  of  the  armed  forces,  the  process  has  only 
been  formalized  to  a  large  degree  for  the  United  States  Air  Force  (USAF)  since  the  late 
1970s,  with  the  institutionalization  of  COMPES.  COMPES  grew  out  of  the  discovery  of 
problems  with  deployments  to  Southeast  Asia  in  1972  through  1973.  Some  of  these 
problems  were  due  to  the  inability  of  various  command-unique  mobility  systems  to  talk  to 
one  another,  except  through  manual  data  translation  (Department  of  the  Air  Force,  1985). 

The  development  of  a  standardized  system  was  chartered  in  1975;  AFR  28-6 
(March  1985)  describes  the  top-level  use  of  the  resultant  COMPES  system.  COMPES 
provides  a  means  of  communicating  OPLANs  from  the  Joint  Chiefs  of  Staff  (JCS)  level  to 
AF  units,  allows  those  units  to  provide  detail  for  materiel  and  personnel  necessary  to  fulfill 
the  OPLANs,  permits  revision  to  OPLANs  and  unit  requirements,  and  coordinates  airlift 
and  shipping  assets.  Existing  computer  hardware  and  networking  capabilities  at  the  time 
of  the  development  of  COMPES  limited  the  degree  to  which  the  original  vision  for  the 
system  could  be  achieved  practically.  New  hardware  capabilities  have  allowed  these 
limitations  to  be  addressed,  as  discussed  in  the  following  section. 

Figure  1  shows  the  basic  structure  of  COMPES  and  the  information  flow  across 
the  chain  of  command.  The  major  modules  of  COMPES  are  LOGMOD,  MANPER,  and 
OPSMOD.  LOGMOD  provides  for  the  planning  of  materiel  shipment  based  on  the 
standard  UTCs,  answering  the  important  question,  "What  do  we  take  on  this  deployment, 
and  in  what  order  do  we  ship  it?"  MANPER  provides  a  similar  capability  for  planning 
personnel  deployments,  "Who  do  we  need  to  send,  and  who  goes  first?"  LOGMOD  and 
MANPER  each  have  a  base  (suffix  "-B")  and  major  command  (suffix  "-M")  component, 
which  are  required  to  communicate  information  to  each  other  as  plans  or  readiness  levels 
change.  This  communication  has  historically  been  inadequate  due  to  low-bandwidth,  low- 
reliability  communications  channels.  OPSMOD  integrates  inputs  from  LOGMOD-M  and 
MANPER-M  (the  MAJCOM  components)  for  consolidated  input  to  the  TOPES,  and  also 
provides  information  from  JOPES  for  those  modules. 
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Figure  1 

COMPES  and  Its  Interfaces 


This  study  focused  on  planning  processes  at  the  unit  level.  LOGMOD-B  and 
MANPER-B  are  the  formal  tools  used,  but  there  is  a  lot  of  informal  planning  done  before 
equipment  and  personnel  lists  get  input  into  these  systems.  The  units  spend  considerable 
time  manually  marking  up  LOGMOD-B  and  MANPER-B  printouts,  entering  them  into 
informal  computer  analysis  tools,  and  eventually  re-entering  the  data  into  the  base 
COMPES  modules.  The  base-level  interviews  indicate  that  much  time  is  currently  wasted 
during  planning  and  execution  deplo5mient  phases  as  a  result  of  re-entering  data  in 
different  formats,  and  that  integration  of  the  existing  systems  either  by  standardization  of 
file  formats  or  development  of  conversion  routines  would  improve  the  situation 
significantly. 

These  problems  have  been  recognized  for  some  time,  and  the  Air  Force  Logistics 
Management  Center  (AFLMC)  and  the  SSC  have  taken  leading  roles  in  addressing  and 
correcting  the  deficiencies.  A  variety  of  new  generation,  integrated  tools  are  currently  in 
development,  and  some  are  well  into  the  field-test  stage. 
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In  general,  the  new  tools  are  targeting  an  "open  systems"  development  approach. 
The  term  "open  systems"  refers  to  the  federal  government's  initiative  to  develop  an  overall 
computing  environment  based  on  open,  consensus-based  standards,  which  will  encompass 
"the  functionality  needed  to  provide  interoperability,  portability,  and  scalability  of 
computerized  applications  across  networks  of  heterogeneous,  multivendor 
hardware/software^ommunications  platforms."  (National  Institute  of  Standards  and 
Technology  Special  Publication  500-210,  1993).  In  current  practice,  this  is  interpreted  to 
mean  Unix  workstations,  X  Windows  user  interfaces.  Initial  Graphics  Exchange 
Specification  (IGES),  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS), 
Graphical  Kernel  System  (GKS),  and  Computer  Graphics  Metafile  (CGM)  graphics 
standards,  and  data  manipulation  (Structured  Query  Language)  and  transport 
(Government  Open  System  Interconnection  Profile)  standards. 

Some  tools  being  considered  are  a  new  version  of  LOGMOD-B,  WCCS,  CMOS, 
and  AMPS.  There  is  also  a  new  version  of  MANPER-B  hosted  on  a  personal  computer. 
Each  of  these  systems  will  enable  significant  improvements  in  various  parts  of  the 
contingency  planning  and  operations  process. 

Upgraded  LOGMOD-B.  If  implemented,  the  new  version  of  LOGMOD-B  will  be 
hosted  on  Sun  and  Hewlett-Packard  (HP)  workstations,  using  the  Unix  operating  system 
and  the  Motif  X-window  user  interface.  Each  wing  Logistics  Plans  office  will  have  a 
workstation  with  five  X-terminals,  laser  and  high  speed  printers.  The  local  machine  will 
be  tied  by  a  high-speed  network  link  to  one  of  eight  Regional  Processing  Centers  (RPCs), 
which  will  act  as  centralized  database  servers.  These  centralized  RPCs  will  give 
MAJCOMs  fijll  visibility  of  the  deployment  data  from  their  respective  bases  (SSC, 
November  1994a). 

The  majority  of  the  functionality  in  the  revised  LOGMOD-B  system  is  essentially 
re-implemented  fi'om  the  original  mainframe  version.  The  big  difference  in  these  existing 
functions  will  be  the  access  speed  to  desired  data  across  the  high-speed  network 
connections.  LOGMOD-B  is  primarily  used  to  create  standard  UTCs  and  tailor  existing 
UTCs  for  specific  OPLANs.  The  new  system  will  allow  much  easier  editing  of  data  with 
the  new  graphical  user  interface  and  will  provide  portability  of  data  formats  across  the 
Standard  Base  Supply  System  (SBSS),  CALM,  CMOS,  MANPER-B,  and  WCCS  for 
mutually  required  data. 

New  functionality  in  the  workstation  version  of  LOGMOD-B  includes  the 
capability  to  view  TPFDD  data  and  query  the  SBSS  to  determine  availability  of  required 
UTC  items. 

CALM.  CALM  is  a  personal  computer  (PC)  -based  software  program  that  allows 
users  to  load  plan  different  transport  aircraft,  including  the  C-130,  C-141,  C-5,  and  KC- 
10.  It  provides  a  graphical  display  of  pallet  locations  on  the  different  aircraft,  allows  users 
to  move  pallets  to  different  locations,  automatically  calculates  center  of  gravity 
restrictions,  and  reads  data  directly  from  electronic  CMOS  inputs.  CALM’s  output  tells 
aircraft  loaders  how  to  position  the  cargo  on  the  flightline  for  loading  onto  the  specified 
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aircraft.  The  latest  version  of  CALM  demonstrated  to  the  study  team  did  not  have 
support  for  Civil  Reserve  Air  Fleet  (CRAF)  aircraft  (747,  DC-8,  etc.),  which  was  one 
weakness  identified  during  the  Desert  Shield/Storm  operations  (Hagel  et  al,  1992). 
CALM  was  apparently  not  widely  used  during  the  Gulf  conflict.  The  Strategic  Air 
Command  (SAC)  bases  involved  in  the  deployment  used  mostly  organic  airlift,  and  the 
“stuff  it  in  until  it  is  full”  method  of  load  planning  was  apparently  common  (Hagel  et  al, 
1992). 


Cargo  Movement  and  Operations  System(CMOS).  CMOS  is  a  software 
application  that  facilitates  inventory  control  on  cargo  being  airlifted  or  shipped.  It 
generates  MILSTAMP-required  shipping  documentation  to  be  attached  to  pallets  and 
provides  for  tracking  of  shipments  in  transit.  It  also  provides  cargo  status  to  the  C2 
elements  and  passes  detailed  cargo  records  via  diskette  to  the  load  planning  program 
(currently  CALM).  CMOS  will  provide  for  hazardous  material  processing  and  identify 
potential  shipment  consolidations  and  packaging  requirements.  In  its  final  form,  it  will 
allow  input  using  hand-held  terminals  (similar  to  units  used  by  overnight  package  delivery 
services),  manual  keyboard  input,  and  radio  frequency  (RF)  scanner  transmissions  (SSC, 
1994). 


Paitomated Mobility  Processing  System  (AMPS).  AMPS  is  a  PC-based  windows 
application  that  allows  the  squadron-level  mobility  planner  to  create  and  modify  equipment 
and  personnel  lists  that  are  electronically  format  compatible  with  the  base-level  COMPES 
(Jennings,  1994).  It  also  provides  the  capability  to  convert  these  files  into  a  form  useable 
by  CMOS  and  to  generate  travel  orders  automatically  from  the  personnel  listings.  Prior  to 
AMPS,  the  unit-level  planner  spent  considerable  time  marking  up  printed  listings  and  re¬ 
entering  them  into  other  automated  systems.  AMPS  allows  "electronic  mark-ups"  to  be 
made  and  fed  directly  into  other  systems  like  LOGMOD-B,  MANPER-B,  CMOS,  and 
CALM.  AMPS  also  provides  for  personnel  immunization  management.  Figure  2  shows 
the  large  number  of  system  interfaces  that  AMPS  has  automated. 
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Figure  2 

Automated  Mobility  Processing  System  (AMPS)  and  Interfaces  with  Other  Tools 


Wing  Command  and  Control  System 

AF  wees  is  a  new  information  system  currently  under  development  by  the  WCCS 
System  Program  Office  (SPO)  at  Gunter  AFB.  The  primary  goal  of  WCCS  is  to  enhance 
the  wing  battle  staffs  access  to  critical  information  from  the  functional  areas  on  an  airbase. 
A  secondary  benefit  will  be  the  resulting  improvement  in  communication  between 
functional  groups. 

WCCS  is  currently  hosted  on  Sun  workstations.  It  uses  a  Motif  graphical  user 
interface  to  give  WCCS  users  rapid  navigation  capabilities  of  the  information  database. 
The  database  is  implemented  using  ORACLE  Version  7,  which  provides  client-server 
functionality  across  the  WCCS  network.  WCCS  is  a  distributed  system,  with  workstation 
nodes  connected  via  high  speed  communications  lines.  Figure  3  shows  a  notional  sketch 
of  the  WCCS  architecture,  including  nodes  for  some  of  the  major  base  information 
providers  and  requesters.  Each  workstation  can  provide  information  quickly  to  the  wing 
battle  staff  and  anyone  else  on  the  network  that  needs  it.  The  minimum  bandwidth  of 
512K  baud  allows  rapid  transmission  of  even  high-resolution  imagery,  such  as  weather, 
maps,  intel  photography,  and  base  damage  assessments  (Science  Applications 
International  Corporation,  1990). 


Figure  3 

Wing  Command  and  Control  System  (WCCS) 

Using  WCCS,  the  battle  staff  can  query  maintenance  for  mission  capable  status  of 
aircraft;  civil  engineering  for  the  condition  of  buildings,  runways,  and  other  base  facilities; 
operations  for  aircraft  and  pilot  scheduling  information;  and  many  other  fiinctional 
organizations.  In  current  operations,  the  battle  staff  has  to  obtain  this  information  through 
phone  calls  and  hand  delivery  of  reports. 

WCCS  is  planned  to  be  a  home  base  as  well  as  a  deployable  system,  which  allows 
it  to  play  a  major  role  in  providing  a  dependable  information  flow  during  a  contingency 
situation.  The  communication  links  at  the  home  base  will  generally  be  standard  copper  or 
fiber  optic  cable,  whereas  WCCS  in  a  deployed  location  will  often  be  based  on  laser  or 
microwave  links  if  a  network  infrastructure  is  not  in  place.  Deployed  WCCS  will  be 
linked  by  satellite  for  electronic  downloading  of  Air  Tasking  Orders.  In  addition  to  the 
current  WCCS  software  applications  in  development,  the  WCCS  network  infrastructure  is 
an  important  capability  in  itself  With  a  high-speed  network  linking  together  all  base 
fimctional  organizations  in  an  open  systems  framewodc,  next  generation  applications  can 
be  developed  with  the  data  distribution  channels  already  in  place.  ECLIPSE  can  take 
advantage  of  this  existing  network  infrastructure. 
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Problem  Areas 

Great  strides  are  being  made  through  the  implementation  of  new  and  upgraded 
planning  systems.  However,  many  of  the  underlying  limitations  associated  with 
contingency  logistics  planning  remain  unchanged.  Planning  centers  on  a  static  UTC, 
manual  calculations,  and  deliberate  planning.  The  results  of  the  literature  search, 
followed  up  by  interviews,  supported  the  findings  listed  below. 

•  Current  wing  logistics  planning/execution  information  systems  are 
”human-in-the-loop"  intensive,  unintegrated,  and  unreliable  at  execution. 

Although  IDS  will  allow  for  automated  entry  of  much  of  the  information  that 
(evidenced  by  Desert  Storm)  requires  a  great  deal  of  manual  pencil  work  and 
rework,  it  does  not  reduce  the  number  of  tasks  that  must  be  accomplished  at 
execution  time.  When  changes  occur  in  the  plan,  the  process  of  tailoring  UTCs  is 
still  a  "stubby  pencil"  process.  The  logistics  planner  is  the  integrator  of  the  "raw" 
data  which  describes  the  deplo5mient  location  and  its  associated  operational 
requirements.  Many  of  the  subjects  interviewed  noted  that  computer 
communications  lines  from  MAJCOM  to  base  level  were  barely  adequate  to 
support  deliberate  planning,  and  that  COMPES  was  not  effective  during  the 
execution  phase.  These  observations  were  borne  out  by  reported  lessons  learned 
from  Desert  Shield/Storm  (Hagel,  1992).  For  example,  telephone  taskings  were 
common  and  were  often  inconsistent  with  later  published  versions  of  the  TPFDL. 

•  Much  of  the  information  that  wing  planners  need  to  accurately  tailor  UTCs 
in  short-notice  situations  is  either  not  available  or  not  accurate.  Information 
on  the  airfields  being  deployed  to  (including  visibility  into  War  Reserve  Materiel 
(WRM))  during  Desert  Storm  was  considered  inadequate  (Hagel,  1992). 
Scheduling  of  airlift  aircraft  was  often  so  unpredictable  that  some  bases  referred  to 
"aluminum  hailstorms"  when  airlifters  arrived  in  large  groups  with  no  notice 
(Hagel,  1992).  Also,  the  types  of  aircraft  arriving  were  often  different  than 
expected.  This  required  load  planning  to  be  re-accomplished  with  tools  not 
designed  to  cope  with  the  range  of  airlifters  encountered. 

•  Even  if  all  of  the  information  needed  to  accurately  tailor  a  UTC  at 
execution  were  available,  the  large  volume  of  information  would  make  it  very 
difficult  for  wing  logistics  planners  to  accurately  replan  a  deployment  in  a 
short  time.  There  is  just  not  enough  time  to  manually  perform  the  desired 
calculations.  No  tools  exist  to  support  "what-if  analyses  based  on  the  anticipated 
tasking.  Many  aircraft  parts  were  apparently  in  overabundance  at  the  deployed 
sites,  but  other  items  were  in  short  supply.  These  included  serious  initial  shortfalls 
in  munitions,  support  equipment  spares,  and  chemical  warfare  equipment. 
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ECLIPSE  VISION 


The  problem  areas  identified  in  this  preliminary  ECLiPSE  study  can  be  summarized 
as  a  lack  of  accurate  and  timely  data,  and  a  lack  of  time  to  adequately  process  that  data  to 
meet  required  deployment  time  lines.  ECLiPSE  provides  a  vision  of  state-of-the-art 
information  systems,  AI,  simulation,  and  communication  systems  to  help  solve  these 
problems  by  making  useful  information  available  during  deployment  planning  and 
execution.  This  task  identifies  three  projects  that  comprise  the  ECLiPSE  vision:  the 
Deployment  Information  &  Support  Environment  (DISE),  Unit  Type  Code  Development, 
Tailoring,  and  Optimization  (UTC-DTO),  and  Logistics  Analysis  to  Improve  Deployability 
(LOG-AID). 


Deployment  Information  and  Support  Environment  (DISE) 

DISE  comprises  two  distinct  parts.  The  first  part  is  a  centrally  located  information 
system  called  the  Deployment  ICnowledge  Base  (DKB).  The  DKB  will  provide  fast  access 
to  audio,  visual,  and  textual  information  pertaining  to  potential  deployment  sites.  It  will 
provide  information  such  as  site-specific  maps,  site-  and  region-specific  lessons  learned, 
airbase  infrastructure  data,  and  information  on  local  suppliers  of  off-the-shelf  resources. 
The  DKB  will  be  an  important  part  of  the  solution  to  the  logistics  planner’s  problem  of 
inadequate  and  inaccurate  information  during  crisis  planning  and  execution 

Although  information  from  UTCs  and  TPFDDs  will  be  much  easier  to  access 
electronically  as  part  of  the  new  systems  currently  under  development,  additional 
information  useful  for  tailoring  UTCs  for  specific  scenarios  is  not  included  in  the  existing 
development  plans.  Much  of  this  data  resides  in  the  WWMCCS  in  a  variety  of  different 
files  and  applications.  However,  this  information  is  very  difficult  to  access  in  the  field 
because  of  the  low  data  transmission  rate  and  unreliable  connections  to  WWMCCS.  A 
good  example  of  the  type  of  information  that  is  difficult  to  access  and  is  very  useful  for 
UTC  tailoring  is  the  AAFIF. 

The  AAFIF  contains  detailed  information  on  more  than  40,000  airfields  worldwide 
which  might  possibly  be  used  for  different  contingency  operations.  For  example, 
information  provided  includes  local  aviation  fuel  supplies;  runway,  taxiway,  and  parking 
area  characteristics;  communications  capabilities;  and  services  available  in  nearby  towns  or 
cities.  The  degree  of  availability  of  a  variety  of  different  items  at  the  specific  deployment 
site  could  drive  significant  additions  or  deletions  to  numerous  UTCs. 

Currently,  access  to  the  AAFIF  through  WWMCCS  is  a  painfully  slow  process 
which  can  take  several  hours  to  download  complete  information  on  one  location.  In 
addition  to  slow  access  due  to  communication  line  limitations,  several  groups  interviewed 
by  the  study  team  (including  HQ  USAF/LGS,  the  366th,  and  the  906th)  questioned  the 
accuracy  and  thoroughness  of  the  WWMCCS  AAFIF. 

The  disadvantages  of  WWMCCS  will  disappear  with  the  implementation  of  the 
DISE  DKB.  The  DISE  DKB  will  provide  fast  user  access  and  rapid  availability  and 
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update  of  new  information.  Conceptually,  the  DKB  will  be  distributed  and  made  available 
to  every  Air  Force  unit  through  satellite  links  and  wide  area  networks.  Users  will  have  the 
capability  to  query  and  edit  the  DKB  from  both  remote  and  local  stations.  The  design 
phase  for  the  DKB  will  include  identification  of  all  types  of  data  that  might  be  useful  to 
deploying  AF  unit  planners.  In  addition  to  the  data  elements  currently  available  in  the 
AAFIF,  the  DKB  could  include  maps,  site  photographs,  real-time  and  projected  weather 
information,  WRM  assets,  host  nation  agreements,  logistics  information  on  units  already 
deployed,  and  transportation  schedules. 

The  amount  of  information  available  in  the  DKB  could  quickly  overwhelm  the  best 
of  planners  if  it  is  not  presented  in  an  organized,  easily  navigated  application.  For  the 
information  to  be  usefUl,  a  good  user-centric  design  will  be  imperative  to  the  DKB 
interface.  Planners  do  not  have  the  luxury  of  being  Internet  surfers.  The  DKB  will  have 
to  leverage  the  best  of  user  interface  design  in  combination  with  the  technologies  of  expert 
systems,  multimedia,  intelligent  databases,  and  distributed  information  systems. 

Populating  the  DKB  with  data  is  a  different  problem  but  no  less  demanding. 
Without  the  correct  data,  the  best  interface  is  useless.  The  second  component  of  DISE 
consists  of  the  input  systems  for  populating  the  DKB.  Currently,  the  two  input 
components  include  MAFIS,  and  ALLRS.  In  addition  to  these,  other  component 
applications  could  be  designed  in  the  future  which  could  easily  be  inserted  into  an  open 
systems  design  of  the  DKB.  One  further  potential  system  currently  under  consideration 
for  addition  to  DISE  is  the  Beddown  Planning  Tool  (BPT),  which  will  be  discussed  later 
in  this  report.  Other  areas  to  investigate  involve  the  development  of  distributed 
collaborative  planning  tools  (including  videoteleconferencing  and  whiteboarding)  and 
document  management  systems,  which  allow  for  scanning  and  cataloguing  of  important 
documents,  which  could  include  orders,  plans,  cargo  manifests,  transportation  schedules, 
and  so  forth. 

Multimedia  Air  Field  Information  System  (MAFIS) 

The  proposed  MAFIS  conceptual  diagram  is  shown  in  Figure  4.  MAFIS  will  be  an 
electronic,  portable  system  with  the  primary  purpose  of  allowing  site  survey  team 
members  to  record  their  observations  directly  into  a  computer.  This  alleviates  the  current 
process  of  delivering  the  handwritten  survey  to  Defense  Mapping  Agency  (DMA)  for  their 
quarterly  update  into  the  AAFIF.  The  data  would  be  available  immediately  at  the  base 
doing  the  site  survey  in  the  new  centralized  database  with  high-speed  data  channels, 
whether  this  be  within  WWMCCS,  the  new  GCCS,  or  a  stand-alone  database.  The  data 
could  be  transferred  to  this  database  via  satellite  to  avoid  any  lag  time.  A  base-level 
component  available  from  any  WCCS  terminal  would  allow  the  selection  of  a  particular 
surbase  and  viewing  of  its  information  through  a  graphical  user  interface  consistent  with 
other  WCCS  functions.  In  addition  to  all  the  information  about  airfields  contained  in  the 
AAFIF,  MAFIS  will  provide  maps,  photographs,  video,  and  audio  associated  with  the 
different  locations.  This  information  is  collected  by  the  site  survey  team. 


17 


Satellite 

link 


Deployed 

Location 


Figure  4 

Multimedia  Air  Field  Information  System  (MAFIS) 


MAFIS  could  actually  be  employed  and  implemented  in  different  ways.  Depending 
on  the  location  of  the  deplo5mient,  MAFIS  will  be  connected  to  the  DKB  either  by  satellite 
link  or  land  network  connection.  In  the  future,  deployments  in  friendly  countries  may 
allow  for  base  network  connections  back  to  the  Continental  United  States  (CONUS), 
while  forward  deployed  locations  will  probably  not  be  able  to  count  on  network  reliability 
due  to  potential  adverse  enemy  action.  Members  of  a  survey  team  might  collect  data 
separately  during  the  day,  then  return  to  the  satellite  transmitter  to  upload  to  the  DKB. 
Alternatively,  each  member’s  MAFIS  unit  could  be  equipped  with  a  wireless  local  area 
network  (LAN)  interface  card.  This  would  allow  immediate  transmission  from  any  team 
member  throughout  the  day  to  a  central  server  PC  unit,  then  through  the  single  satellite 
transmitter  to  the  DKB.  Within  a  year,  wireless  LAN  technology  should  reach  the  point 
of  enabling  such  a  PC  system  for  less  than  $200  each. 

MAFIS  usage  would  not  be  limited  to  the  initial  survey.  It  could  also  be  deployed 
with  the  unit,  providing  valuable  time-critical  information  back  to  the  DKB  and  home  base 
as  conditions  change.  Videoteleconferencing  could  be  implemented  using  the  MAFIS 
hardware,  possibly  by  integrating  commercial  off-the-shelf  (COTS)  software. 
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Technologies  required  for  MAFIS  involve  the  integration  of  multimedia 
information  with  intelligent  databases  over  wide  and  local  communications  netwoife. 
Using  these  technologies,  MAFIS  will  significantly  improve  the  speed  of  transmission  and 
quality  of  data  about  deployment  locations. 


Automated  Lessons  Learned  Recording  System  (ALLRS) 

ALLRS  will  provide  for  the  collection  of  quantitative  data  involving  problems 
experienced  during  an  in-theater  tour,  and  the  recording  of  user-specified  problems  and 
solutions.  This  capability  provides  a  real-time  look  at  the  conditions  at  deployed 
locations,  enabling  units  on  subsequent  deployments  to  the  same  or  like  locations  to  make 
faster,  more  accurate  plans.  Figure  5  depicts  the  architecture  that  will  enable  this  to 
happen. 


ALLRS  will  be  connected  as  a  node  on  a  LAN  at  a  deployed  base.  This  network 
infrastructure  will  be  part  of  the  environment  currently  envisioned  for  WCCS,  LOGMOD- 
B,  SBSS,  or  something  yet  to  be  defined,  which  will  provide  basic  connectivity  to  the 
base.  ALLRS  will  consist  of  one  or  more  workstations  running  an  operating  system  and 
user  interface  that  will  provide  it  with  a  look  and  feel  very  similar  to  all  other  applications 
on  the  deployed  open  systems  network.  ALLRS  will  employ  a  database  management 
system,  either  one  of  several  commercial  object-oriented  systems  or  the  Oracle  Relational 
Database  Management  System  (RDBMS)  Version  7,  which  is  already  being  used  for 
WCCS.  This  database  will  be  used  to  store  all  the  lessons  learned  data  collected. 

ALLRS  could  be  implemented  on  an  existing  open  systems  network,  whether  it  is 
WCCS,  LOGMOD-B,  or  SBSS.  Different  ways  of  obtaining  the  desired  data 
automatically  from  the  network  are  described  in  Appendix  A,  and  these  modes  can  be 
combined  to  obtain  a  balance  between  utility  and  ease  of  implementation.  Automatic 
collection  of  data  is  useful  in  monitoring  many  different  types  of  information  that  wll  be 
very  interesting  to  the  person  who  will  be  in  the  same  spot  three  months  in  the  future, 
without  requiring  full-time  data  entry  people  at  the  deployed  site.  Once  a  deployed 
network  is  in  place,  an  ALLRS  node  wall  just  sit  on  the  network  and  listen  to  the 
information  traffic,  requesting  pieces  of  data  it  has  been  set  up  to  retrieve.  As  soon  as  the 
local  network  has  recorded  the  information,  ALLRS  will  automatically  transfer  to  the 
DKB  the  quantities  and  status  of  spares,  support  equipment,  munitions,  and  vehicles. 
Daily  weather  information  and  forecasts  from  wing  weather  servers  can  be  transmitted. 
Operational  information  on  sortie  generation,  aborts,  completion,  and  mission  success 
could  be  captured  as  well.  This  information  is  valuable  not  only  to  the  next  deploying  unit 
but  to  the  currently  deployed  unit.  The  home  base  can  monitor  supply  status  in  real  time 
and  help  expedite  the  resupply  process,  taking  some  of  the  burden  from  the  deployed 
supply  personnel. 

In  addition  to  the  automatic  collection  mode,  ALLRS  will  include  a  client  interface 
that  will  allow  any  other  human-attended  node  on  the  deployed  network  to  connect  to  the 
ALLRS  lessons  learned  server.  With  a  mouse  click,  users  on  the  base  network  will  be  able 
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to  bring  up  a  user  interface  that  allows  them  to  enter  lessons  that  they  are  in  the  process 
of  learning.  Instead  of  waiting  to  file  “after-action”  reports,  problems  can  be  entered  as 
they  occur,  time-stamped,  keyworded,  and  separated  by  functional  and  geographic  areas. 
During  Desert  Shield/Storm,  many  problems  never  made  it  into  the  Joint  Universal 
Lessons  Learned  System  (JULLS),  but  were  buried  in  trip  reports  or  people’s  memories, 
to  be  manually  dragged  out  later  by  organizations  doing  studies  of  “what  happened?” 
(Hagel,  1992).  Not  only  will  the  ALLRS  client  program  capture  more  of  the  problems 
encountered,  it  will  provide  for  the  possibility  of  cross-referencing  the  user-entered 
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Figure  5 

ALLRS  as  a  Node  on  a  Deployable  Network 

problem  with  the  automatically  collected  data  from  ALLRS,  potentially  helping  to  find  the 
root  cause  much  faster. 

Finally,  ALLRS  can  be  used  effectively  at  home  bases.  It  can  help  a  unit  find 
problems  with  its  normal  processes  and  rapidly  address  them.  In  addition,  information 
from  different  home  bases  can  still  be  fed  into  the  central  DKB  where  other  units  can  see 
it.  These  other  units  can  find  information  on  problems  someone  else  has  already  solved, 
or  information  from  a  base  that  might  be  similar  to  the  anticipated  deplo5mient  location. 


Unit  Type  Code  Development,  Tailoring,  and  Optimization  (UTC-DTO) 

UTC-DTO  comprises  of  two  subcomponents:  an  automatic  UTC  development  and 
tailoring  capability  and  an  automatic  palletization  optimization  system.  These  tools  will 
provide  a  critical  improvement  to  the  rapid  planning  process  by  analyzing  the  information 
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in  the  DKB  and  making  recommendations  to  the  planner.  This  “sifting”  of  the  DKB  is 
necessary  to  keep  the  planner  from  being  saturated  by  too  much  good,  but  raw, 
information.  The  development  and  tailoring  capability  component  will  help  deployment 
planners  rapidly  develop  or  tailor  UTCs  for  specific  deployment  missions.  During  a  crisis, 
this  component  will  highlight  all  the  items  in  the  tasked  UTC  that  need  to  be  tailored  out 
of  the  package  by  using  information  stored  in  the  DKB  along  with  other  important  pieces 
of  information  as  inputs  to  the  automatic  tailoring  process.  The  automatic  palletuation 
optimization  system  component  will  help  unit  personnel  palletize  cargo  by  automatically 
generating  near-optimal  pallet  arrangements  (smallest  cube  vs.  maximum  weight  and 
within  aircraft  dimensional  and  center  of  gravity  limitations)  based  on  the  tailored  UTCs. 


Development  and  Tailoring 

The  development  and  tailoring  system,  shown  in  Figure  6,  has  two  primary 
fiinctions; 

1.  providing  real-time  site-specific  information  to  the  wing-  and  squadron-level 
contingency  planner,  and 

2.  automatically  tailoring  UTCs  based  on  this  information. 

Information  obtained  through  the  DISE  system  would  be  provided  at  the  UTC- 
DTO  workstation.  To  aid  in  planning  specific  deployments,  the  planner  would  have  rapid 
access  to  all  site  survey  information,  as  well  as  lessons  learned  on  previous  deployments. 
This  information  would  be  accessed  by  selecting  either  specific  locations  (airfields), 
regions,  or  climatic  conditions,  and  by  using  the  keyword-indexed  retrieval  and  free  text 
search  functions.  As  stated  previously,  electronic  collection  of  this  data,  as  well  as  high¬ 
speed  delivery  to  the  field,  is  critical  to  pro\ide  current  information.  Planners  would  be 
able  to  look  at  detailed  information  on  the  specific  base  for  which  they  are  planning  a 
deployment,  or  similar  bases  in  cases  where  the  target  base  has  not  previously  been  a 
"deployed-to"  location.  The  information  would  be  provided  in  different  \dews,  from  maps 
and  hyperlink  photographs  of  significant  airfield  features,  to  fixed  format  windows  giving 
standard  airfield  information  such  as  runway  descriptions,  fuel  capacities,  medical 
facilities,  and  the  like,  to  narrative  windows  describing  past  problems  and  solutions 
encountered. 

All  the  information  on  the  UTC-DTO  workstation  could  be  used  to  support 
manual  tailoring  of  deployment  requirements,  as  well  as  to  support  the  generation  of 
reports  relevant  to  various  fimctional  organizations.  In  addition,  the  UTC-DTO  system 
will  have  the  capability  to  load  standard  UTC  packages  and  use  MAFIS  and  ALLRS  to 
automatically  provide  tailoring  recommendations.  After  specifying  the  desired  UTCs, 
planners  would  select  a  specific  airfield  and  optionally  a  lessons  learned  database  to  be 
loaded  into  their  workspace.  UTC-DTO  would  take  relevant  parts  of  the  two  databases 
loaded  and  determine  their  effects  on  the  UTCs  selected.  Much  of  the  data  in  MAFIS  and 
ALLRS  can  be  associated  with  rules  to  govern  quantities  of  manpower  and  materiel.  New 
UTCs  would  be  created  and  displayed  to  users  in  a  context-sensitive  editor,  with 
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recommended  changes  to  the  standard  UTCs  highlighted.  Planners  could  look  at 


recommended  additions  or  increases  (highlighted  in  blue)  and  recommended  deletions  or 
decreases  (highlighted  in  red)  in  equipment  and  manpower  levels,  and  decide  whether  to 
accept  all  or  part  of  the  recommended  tailoring.  The  capability  would  exist  to  also 
add/delete  requirements  manually,  based  on  the  planner’s  experience,  information  in 
MAFIS  or  ALLRS  which  is  not  associated  with  a  tailoring  rule,  or 
recommendations/directions  from  other  sources.  Once  the  automatic  and  manual  tailoring 
is  complete,  the  new  UTCs  will  be  transferred  automatically  to  LOGMOD-B  and 
MANPER-B  for  eventual  uploading  into  the  MAJCOM  components  of  COMPES.  The 
open  systems  network  connection  will  also  allow  all  functionals  to  view  and  potentially 
edit  relevant  parts  of  the  tailored  UTCs. 
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Pallet  Optimizer 

The  pallet-optimization  component  of  UTC-DTO  is  envisioned  to  be  the  next 
logical  step  in  automated  load  planning.  It  will  take  the  experience  of  the  CALM  system 
and  extend  it  to  allow  expert  load  planners  to  set  up  rule  bases  for  different  aircraft. 
Given  input  cargo  and  personnel  listings  generated  from  the  development  and  tailoring 
system,  the  pallet  optimizer  will  use  these  rules  to  automatically  generate  optimal  plans  for 
the  specific  cargo  on  the  463C  pallets. 


Logistics  Analysis  to  Improve  Deployability  (LOG-AID) 

The  ECLIPSE  task  has  provided  much  insight  into  the  problems  associated  with 
deploying  large  forces  to  distant  locations.  It  has  also  generated  research  ideas  (DISE  and 
UTC-DTO)  that  can  be  exploited  now  to  improve  wing-level  deployment  planning. 
However,  this  task  revealed  just  enough  about  the  current  problems  associated  with  wing- 
level  deployment  planning  to  demonstrate  that  a  much  deeper  analysis  is  required.  LOG- 
AID  will  investigate  wing-level  deployment  to  further  investigate  and  refine  user 
requirements  and  desires  for  future  deplo3mient  planning  resources.  The  purpose  of  this 
study  is  to  identify  advanced  technologies  and  processes  that  have  the  potential  to  improve 
wing-level  (and  wing  equivalent  units  of  the  other  services)  deployment  planning  and 
execution,  reduce  mobility  footprint,  reduce  deployment  response  time,  and  use  mobility 
resources  more  effectively  and  efficiently.  More  specifically,  LOG-AID  will; 

•  build  on  the  original  ECLIPSE  study  effort  and  the  HQ  USAF  Integrated 
Definition  (IDEF)  deployability  study; 

•  further  analyze  Air  Force  requirements  associated  with  deployment  planning; 

•  analyze  deplo5mient  planning  processes  of  the  Army,  Navy,  and  Marine  Corps; 

•  solicit  user  requirements  for  future  deployment  planning  tools,  systems,  and 
processes;  and 

•  suggest  innovative  processes  and  technologies  to  satisfy  user  requirements  in 
the  deployment  planning  arena. 

The  information  gathered  to  support  LOG-AID  will  come  from  (but  will  be  not 
limited  to)  the  original  ECLIPSE  Requirement  Study,  the  HQ  USAF/LGX  IDEF 
deployability  study,  interviews  with  deployment  planners  (users)  at  the  wing-level  (and 
wing  equivalent  units  of  the  other  services),  observations  of  wing-level  (and  wing 
equivalent  units  of  the  other  services)  deployment  planners  performing  deployment 
planning  (either  during  real-world  deployments  or  base  exercises),  and  a  survey  instrument 
which  asks  users  for  their  requirements  and  desires  for  future  deplo)mient  planning 
resources. 
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ENABLING  TECHNOLOGIES 


The  efiforts  on  this  task  involved  studying  several  new  technologies  that  could  be 
beneficial  in  the  ECLiPSE  system.  Areas  examined  include  desktop  videoconferencing 
with  collaborative  planning,  case-based  reasoning,  satellite  communications,  and  intelligent 
databases. 

Desktop  videoconferencing  would  greatly  enhance  the  communication  capabilities 
between  airfield  surveyors  and  any  other  location.  With  current  practices, 
communications  outside  the  airfield  are  sometimes  very  difficult  because  of  a  lack  of 
suitable  communication  equipment  on  the  site.  Desktop  videoconferencing  capabilities 
built  into  MAFIS  would  allow  for  a  reliable  and  consistent  communications  medium  that  is 
independent  of  on-site  equipment.  Therefore,  a  study  on  desktop  videoconferencing 
systems  was  performed.  An  analysis  of  several  different  products  available  for  Macintosh, 
Windows  and  Sun  systems  was  completed.  Different  capabilities  were  examined, 
including  communication  fimctionality,  cross-platform  compatibility,  conformance  to 
videoconferencing  standards,  the  number  of  allowable  conference  participants  and 
information-sharing  capabilities  (e.g.,  a  shared  whiteboard,  file  transferring  and  application 
sharing). 

MAFIS  also  depends  on  the  availability  of  easily  portable  computers  and  satellite 
communication  equipment.  A  study  was  performed  on  the  SPORTS  and  ImageHawk 
systems,  two  products  that  provide  easily  portable  data  collection  and  transmission 
capabilities.  A  satellite  communication  system  called  International  Marine  Satellite  version 
B  (INMARSAT-B)  was  also  examined.  This  system  provides  global  coverage  and  is  also 
easily  portable.  It  allows  for  high-speed  transmission  of  data,  including  faxes,  audio,  and 
video  clips.  Videoconferencing  is  also  possible  through  an  INMARSAT-B  connection. 

ALLRS  requires  a  method  of  storing  lessons  learned  and  determining  which 
previous  lessons  apply  to  a  current  mobilization.  An  AI  technology  called  case-based 
reasoning  is  well-suited  to  this  task.  This  methodology  allows  previous  experience  to  be 
cataloged  into  separate  cases.  These  cases  are  then  stored  in  a  central  database.  When  a 
new  situation  arises,  it  is  compared  to  each  case  in  the  database.  The  solutions  to  the 
cases  that  most  closely  resemble  the  new  case  are  recommended.  A  solution  to  the  new 
case  can  then  be  recommended,  and  the  new  case  is  added  to  the  database.  This  allows 
the  database  to  continually  grow,  thereby  allowing  the  system  to  learn  and  become  more 
proficient  at  correctly  solving  problems  previously  unencountered. 

A  crucial  factor  to  the  successful  operation  of  the  UTC-DTO  system  is  the  ability 
to  extract  meaningful  information  from  different  databases  such  as  WWMCCS  and  GCCS. 
Traditional  database  functionality  has  proven  to  be  very  limited  in  providing  useful 
information.  Therefore,  a  study  was  performed  on  the  relatively  new  concept  of  intelligent 
databases.  These  data  bases  combine  traditional  database  functionality  with  technologies 
such  as  object-oriented  programming,  expert  systems,  hypermedia,  and  on-line 
information  retrieval.  The  result  is  a  methodology  that  allows  for  the  easy  extraction  of 
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information  from  large,  complex  databases.  This  ability  is  even  more  important  to  systems 
such  as  ECLiPSE  that  directly  support  decision-making  tasks. 

Desktop  Videoteleconferencing 

Videoconferencing  is  a  relatively  new  technology  that  pro\ides  fUll  audio  and 
video  capabilities  to  conference  members  at  the  source  and  one  or  more  remote  locations. 
Speakerphones  and  conference  calls  are  commonplace  in  today's  working  environment, 
but  they  lack  the  live  video  component.  Non-verbal  communication  can  now  be  achieved, 
and  visual  displays  such  as  charts  or  models  can  be  conveyed  without  resorting  to  a  fex 
machine  or  verbal  descriptions.  Quite  simply,  videoconferencing  is  "the  next  best  thing  to 
being  there." 

Videoconferencing  capabilities  have  recently  been  introduced  to  desktop 
computers.  One  benefit  is  that  conference  members  do  not  have  to  go  to  a  specific 
location  equipped  with  a  videoconferencing  system.  Instead,  members  can  participate  in  a 
videoconference  right  at  their  own  desks.  Perhaps  an  even  greater  advantage  lies  in  the 
fact  that  members  of  a  desktop  videoconference  can  share  data.  For  example,  one 
member  might  have  a  chart  he  wishes  to  show  to  the  others.  With  this  capability,  the  chart 
would  show  up  on  any  or  all  of  the  others'  screens  through  a  shared  whiteboard.  Some 
software  packages  have  a  capability  called  application  sharing.  This  allows  any  participant 
to  view  and  edit  data  from  a  remote  machine.  Thus,  if  one  member  has  a  WordPerfect 
document,  the  others  can  use  WordPerfect  to  view  and  edit  the  document  even  if  the 
application  is  only  installed  on  the  host  machine. 

Since  desktop  videoconferencing  is  such  a  new  technology,  there  currently  are  no 
standards  that  fully  define  desktop  video  capabilities.  Standards  such  as  H.320  are 
designed  solely  for  video  and  audio  transmission;  therefore,  they  do  not  provide 
specifications  for  the  data  transfer  necessary  for  shared  whiteboard  and  application-sharing 
capabilities.  Consequently,  most  products  examined  use  a  proprietary  format  that 
prohibits  interoperability  with  other  systems,  so  a  Sun  SPARCstation  with  ShowMe 
cannot  engage  in  a  videoconference  with  an  Apple  Macintosh  running  Cameo.  Some 
companies  have  instead  made  versions  of  their  products  that  run  on  different  platforms. 
For  example,  InSoft  makes  different  versions  of  Communique!  for  Sun  workstations  and 
PCs  running  Windows.  The  video  and  audio  conferencing  capabilities  are  there,  but  other 
features  such  as  application  sharing  are  not. 

There  are  two  modes  that  videoconferencing  systems  operate  under,  LANs  and 
phone  lines.  When  phone  lines  are  used,  they  will  be  Integrated  Services  Digital  Network 
(ISDN),  Switched  56,  or  analog.  Many  products  operating  under  Switched  56  or  analog 
use  two  phone  lines  for  videoconferencing,  one  for  the  video  signal  and  one  for  audio. 

There  are  many  desktop  \ddeoconferencing  systems  available  for  the  different 
computer  platforms.  Several  of  these  are  described  in  Appendix  B. 
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Portable  Computing/Satellite  Communications 


The  key  element  of  MAFIS  is  a  computer  system  capable  of  capturing  textual, 
graphical,  video,  and  audio  data.  The  system  must  be  easily  portable  in  order  to  minimize 
the  encumbrance  of  the  airfield  survey  team  members.  Also,  the  system  must  have  a  way 
of  easily  and  quickly  transmitting  the  accumulated  data  to  a  central  location  for  inclusion 
in  a  major  database.  Due  to  the  global  variety  of  potential  MAFIS  sites,  the  system  must 
be  able  to  communicate  through  satellite  links  since  other  means  may  not  be  possible. 
INMARSAT-B  is  a  widely  used  satellite  communication  methodology  that  is  very 
applicable  to  ECLIPSE.  INMARSAT-B's  flexibility  and  high  transmission  rates  allow  for 
capabilities  such  as  data  transfer  (audio  and  video  data  included),  faxing  and 
videoconferencing.  A  large  network  of  satellites  and  ground  stations  provide  global 
coverage.  This  system  is  discussed  in  depth  in  Appendix  C. 

TASC  offers  two  products,  SPORTS  and  ImageHawk,  which  provide  the 
capabilities  mentioned  above.  Both  are  designed  to  be  remote-location  data-collection 
tools  that  have  the  capability  to  communicate  through  an  INMARSAT  system.  These 
products  are  discussed  in  Appendix  D. 

To  automate  the  Standardized  Airfield  Survey  Checklist,  extensive  database 
software  needs  to  be  written.  This  will  probably  involve  the  use  of  object-oriented 
databases  to  develop  a  fully  operational  MAFIS.  The  difficult  items,  such  as  setting  up 
communication  methods,  designing  the  physical  system  for  portability,  and  incorporating 
true  multimedia  capabilities,  have  been  successfiilly  demonstrated  by  the  SPORTS  and 
ImageHawk  products. 


Case-Based  Reasoning 

ALLRS  needs  a  method  to  generate  new  lessons  learned  "records"  and  store  them 
in  the  lessons  learned  database.  UTC-DTO  needs  a  way  to  scan  the  Lessons  Learned 
Data  Base  (LLDB)  and  retrieve  any  lessons  that  are  comparable  to  the  current  situation. 
Both  tasks  are  difficult;  however,  an  AI  technology  called  Case-Based  Reasoning  (CBR) 
has  proven  to  be  very  proficient  at  performing  these  tasks.  Appendix  E  provides  a 
detailed  explanation  of  the  CBR  technology. 

CBR  systems  are  usefixl  when  the  problem  domain  is  not  totally  understood.  This 
is  the  case  with  contingency  planning  because  there  are  so  many  factors  involved  that  it 
would  be  extremely  difficult  to  develop  a  sufficient  rulebase.  The  capabilities  of  operating 
with  missing  data  and  handling  non-numerical  data  also  make  CBR  a  viable  approach  for 
ECLIPSE. 

The  volume  of  data  that  will  be  entered  into  the  ECLiPSE  system  mandates  a 
technique  that  allows  for  simple  data  entry.  As  discussed  in  Appendix  E,  statistical  pattern 
recognition,  expert  systems,  and  neural  networks  do  not  offer  easy  ways  to  add  data  to  the 
system.  CBR  systems,  on  the  other  hand,  allow  users  to  add  information  to  the  system 
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through  data  entry  forms.  The  new  case  will  be  indexed  and  become  part  of  the  LLDB  for 
future  use. 

A  CBR  system  can  be  integrated  into  ECLiPSE  so  that  it  is  accessed  by  both  the 
ALLRS  and  UTC-DTO  subsystems.  An  initial  LLDB  must  first  be  generated.  After  it  is 
put  in  use,  new  cases  will  be  regularly  added  through  the  ALLRS  system.  As  contingency 
planners  submit  lessons  learned  to  ALLRS,  the  lessons  are  added  and  indexed  for  fijture 
retrieval. 

When  the  UTC-DTO  subsystem  is  being  used  to  plan  a  mobilization,  the 
contingency  planners  will  input  the  features  of  the  situation  into  the  CBR  system.  Any 
cases  that  suitably  compare  with  the  current  one  will  be  displayed,  showing  the  results  of 
previous  lessons  learned.  These  results  will  contain  suggested  additions  and  deletions  to 
standard  UTCs  that  previous  contingency  planners  deemed  appropriate.  Planners  can  then 
modify  a  retrieved  case  to  match  the  current  one.  This  new  case  will  then  be  entered  into 
the  LLDB. 

As  cases  are  added  through  both  the  ALLRS  and  UTC-DTO  subsystems,  the  CBR 
system  becomes  more  powerful  and  the  likelihood  of  retrieving  an  exact  match  continues 
to  increase.  Therefore,  the  need  to  modify  retrieved  cases  that  are  close  to  the  input 
situation  is  reduced.  Eventually,  case  modification  vrill  only  need  to  be  done  on  rare 
occasions.  Quite  simply,  a  CBR  system  used  in  ECLiPSE  will  give  contingency  planners 
access  to  the  experience  of  every  person  that  has  previously  planned  and  executed  a 
mobilization. 


Intelligent  Databases 

Intelligent  databases  can  loosely  be  defined  as  databases  that  manage  information 
in  a  natural  way,  making  that  information  easy  to  store,  access,  and  use  (Parsaye  et  al., 
1989).  This  concept  has  grown  out  of  a  need  for  end  users  to  get  more  effective  use  out 
of  information  systems.  Discussed  here  are  some  limitations  of  the  current  database 
technology,  and  ways  in  which  intelligent  database  concepts  overcome  some  of  those 
limitations. 

As  the  amount  of  information  contained  in  one  "store"  increases,  it  becomes 
increasingly  difficult  to  use  that  information  efficiently.  Similarly,  it  becomes  increasmgly 
difficult  to  verify  the  accuracy  of  the  information.  Storing  information  in  computer 
databases  decreases  the  level  of  this  problem.  Data  in  databases  can  be  accessed  by 
queries  based  on  values  contained  in  individual  entries  or  keywords  associated  with  those 
entries.  Once  information  of  interest  is  found,  it  can  be  retrieved  immediately  and 
presented  to  the  user.  Also,  integrity  checks  can  be  performed  on  databases  to  ensure 
certain  simple  errors  are  not  present  in  the  data.  Traditional  databases,  however,  only 
begin  to  address  the  problems  of  usability  and  data  integrity  of  large  information  systems. 
Most  modem  information  systems  use  relational  database  management  systems 
(RDBMSs)  which  are  limited  to  some  very  basic  capabilities. 
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Database  integrity  support  is  generally  limited  to  referential,  non-null,  and  type. 
Referential  integrity  prevents  one  database  entry  from  referring  to  another  entry  which 
does  not  exist.  Non-null  integrity  prevents  certain  fields  from  being  left  blank.  This  is 
usually  known  as  "entity  integrity"  (Elmasri  &  Navathe,  1989)  because  it  usually  applies  to 
primary  keys.  Type  integrity  prevents  information  of  the  wrong  type  from  being  stored  in 
a  database  field  (e.g.,  text  data  cannot  be  stored  in  a  numeric  field).  It  would  be  useful  for 
the  database  to  enforce  more  sophisticated  integrity  constraints.  A  simple  example  might 
be  to  limit  the  range  of  valid  values  for  a  runway  length  to  positive  values.  An  even  more 
sophisticated  capability  might  allow  the  database  to  discover  and  suggest  its  own  integrity 
constraints. 

Queries  are  limited  to  SQL  or  Query  by  Example  (QBE).  Both  query  types  are 
limited  to  relatively  simple  queries  such  as,  "Select  airbases  where  runway  length  >= 
5000."  Although  the  queries  may  access  multiple  tables  and  contain  compound  boolean 
expressions,  they  must  explicitly  define  the  information  that  should  be  returned.  A  more 
useful  query  language  might  allow  queries  such  as,  "Select  airbases  where  bombers  are 
supported."  The  database  would  then  determine  the  characteristics  that  are  needed  for 
bomber  support  and  which  airbases  satisfy  those  requirements. 

RDBMSs  do  not  directly  support  viewing  and  traversing  the  information  they 
contain.  They  simply  store  data  and  return  the  data  requested  by  queries.  The  only  views 
they  are  aware  of  are  flat  sets  of  records.  Most  applications  must  implement  predefined 
routes  for  traversing  the  database.  Ideally,  a  user  should  be  allowed  to  traverse  and  view 
information  in  a  database  in  a  manner  that  is  natural  to  them. 

Only  a  limited  set  of  data  types  are  supported  by  RDBMSs.  Traditionally, 
information  stored  in  databases  is  either  numeric,  character,  or  a  special  case  of  one  of 
those  two  (e.g.,  a  date  is  a  special  character  field).  Support  for  data  types  like  images, 
audio,  and  video  is  very  limited. 

Capabilities  that  go  beyond  the  limitations  listed  above  are  not  directly  supported 
by  RDBMSs.  When  needed,  these  capabilities  must  be  implemented  by  the  application 
programs  accessing  the  database  system.  This  causes  application  programs  to  re¬ 
implement  similar  capabilities.  It  also  causes  inconsistencies.  For  example,  one 
application  may  constrain  airbase  runway  length  to  positive  values,  another  may  constrain 
it  to  values  greater  than  100.  Furthermore,  when  constraints  change,  changes  to  the 
application  are  usually  necessary. 

RDBMSs  continue  to  evolve;  however,  they  still  fall  short  of  providing  the 
fixnctionality  required  by  many  applications.  In  an  effort  to  address  the  restrictions  of 
RDBMSs,  a  concept  called  "intelligent  databases"  has  developed.  Intelligent  databases 
represent  a  new  technology  for  information  management  that  has  evolved  as  a  result  of  the 
integration  of  traditional  approaches  to  databases  with  more  recent  fields  such  as  object- 
oriented  programming,  expert  systems,  hypermedia,  and  on-line  information  retrieval 
(Parsaye  et  al.,  1989).  The  integration  of  these  technologies  would  create  an  information 


28 


system  that  could  ofifer  users  capabilities  that  go  beyond  the  previously  mentioned 
restrictions. 

Current  database  engines  do  not  encompass  all  the  technology  included  in  this 
definition  of  intelligent  databases.  At  this  stage,  the  intelligent  database  is  more  of  a 
concept  than  a  tool.  However,  the  individual  technologies  are  evolving  to  the  point  where 
they  can  more  easily  be  integrated  when  developing  an  information  system. 

Object-oriented  technology  is  evolving  quickly.  Object-oriented  programming  has 
already  been  integrated  with  database  technology.  There  are  many  commercial  object- 
oriented  database  management  systems  (ODBMSs);  these  systems  primarily  address  three 
RDBMS  limitations.  First,  they  expand  database  integrity  support.  By  encapsulating  data 
and  functionality,  objects  provide  a  natural  place  to  implement  complex  integrity 
constraints  that  all  data  access  must  pass  through.  Second,  they  extend  the  data  types. 
ODBMSs  support  complex  user-defined  types.  Third,  they  allow  direct  links  from  one 
database  object  to  another,  thus  allowing  database  traversal  without  constructing  queries. 

Expert  systems  have  had  moderate  success  in  niche  markets  such  as  system 
diagnosis.  Expert  systems  are  now  adding  object-oriented  capabilities.  This  creates  the 
possibility  of  integrating  expert  system  technology  with  ODBMS  technology.  Marrying 
the  expert  system's  "knowledge  base"  of  rules  with  the  object  language's  class  structure 
proves  to  be  a  natural  and  sensible  approach  (Bloor,  1993).  This  "marriage"  would  allow 
end  users  to  add  rules  to  the  system.  These  rules  could  be  used  by  the  expert  system  to 
perform  its  traditional  role  processing  the  rules  for  data  constraint  and  reasoning,  thereby 
eliminating  the  need  for  all  data  constraints  and  logic  to  be  programmed  into  the 
application. 

Hypermedia  is  defined  as  the  use  of  data,  text,  graphics,  video,  and  voice  as 
elements  in  a  hypertext  system.  All  the  various  forms  of  information  are  linked  together 
so  that  a  user  can  easily  move  from  one  to  another.  Hypermedia  is  among  the  fastest 
growing  sectors  of  computer  technology  (Jovanovic  &  Mrdalj,  1993).  Hypermedia  and 
ODBMS  technology  closely  parallel  each  other.  Hypermedia  allows  links  between 
information  that  is  viewed;  ODBMSs  allow  links  between  information  that  is  stored. 
Implementing  a  hypermedia  system  on  top  of  a  ODBMS  would  allow  users  to  traverse  the 
database  at  will. 

On-line  information  retrieval  is  concerned  v^th  the  representation,  storage,  and 
accessing  of  information.  One  basic  method  of  retrieval  is  to  index  information  using 
keywords.  This  allows  fast  retrieval  of  information  based  on  keyword  selection.  This 
usually  requires  manually  entering  keywords  when  information  is  added  to  the  database. 
More  advanced  retrieval  methods  use  automated  indexing  of  information  based  on  its 
content.  Automated  indexing  is  often  based  on  statistical  analysis  of  the  information 
(Parsaye  et  al.,  1989).  This  eliminates  the  need  for  users  to  define  keywords  for 
information  entered  in  the  system. 
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Intelligent  databases  do  not  currently  exist  as  stand-alone  tools.  However,  the 
technologies  encompassed  by  the  intelligent  database  concept  can  be  used  to  overcome 
some  limitations  of  traditional  databases.  Any  large,  complex  information  system  should 
strive  to  integrate  the  technologies  associated  with  the  intelligent  database  concept  to 
increase  their  usability.  This  is  especially  true  of  systems  designed  to  directly  support 
decision-making,  such  as  ECLiPSE. 


AREAS  FOR  FURTHER  RESEARCH 

This  task  provided  a  great  deal  of  useful  information  about  some  of  the  current 
problems  associated  with  wing-level  deployment  planning,  initiated  research  of  several 
systems  that  will  overcome  some  of  these  problems  (DISE  and  UTC-DTO),  and 
demonstrated  the  need  for  a  more  detailed  requirements  study  of  the  wing-level 
deployment  process  (LOG-ADD).  Due  to  time  and  money  restraints,  not  all  of  the  ideas 
that  surfaced  during  this  task  transitioned  into  actual  research  projects.  The  two  most 
noteworthy  of  these  ideas  are  the  Beddown  Planning  Tool  and  the  Capability  Assessor. 
The  following  paragraphs  outline  these  areas,  which  are  outstanding  candidates  for  further 
research. 


Beddown  Planning  Tool 

The  Beddown  Planning  Tool  (BPT)  will  provide  the  capability  to  set  up  detailed 
plans  for  the  deployment  site.  Site  planners  at  deployed  locations  need  to  evaluate  the 
effect  on  their  base  of  having  several  units  hosted  as  temporary  tenants.  Capt  Wayne  C. 
Foote  (Foote,  1993)  wrote  about  the  steps  in  this  process  with  regard  to  several  different 
major  areas;  potential  scenarios,  augmentation,  billeting,  messing,  civil  engineering, 
maintenance,  munitions,  security,  supply,  fuels/fluids,  transportation,  and  base  actions. 
Many  of  the  items  that  he  urged  be  addressed  involved  procedures  that  should  be  put  in 
place  to  ensure  smooth  operations  during  a  deployment.  Many  of  the  other  issues 
involved  with  planning  for  a  large  temporary  tenancy  can  be  enhanced  by  the  use  of 
computers.  The  BPT  specifically  is  envisioned  to  allow  the  graphical  layout  of  a  base  and 
the  considerations  that  involve  spatial  planning  to  be  accomplished  on  a  computer.  Some 
of  the  plans  normally  done  manually  involve  aircraft  parking,  tent  cities,  messing  facilities, 
building  conversion  to  alternate  uses,  aircraft  shelters,  hot-pit  points,  munitions  storage 
and  assembly  areas,  security  points,  perimeter  defense,  aircraft  tank  buildup  locations, 
additional  supply  storage,  and  fuel  bladder  locations.  All  of  these  could  benefit  from  the 
use  of  computer  technology,  in  terms  of  both  faster  planning  and  better  plans. 

At  least  one  effort  is  currently  in  development  to  address  some  of  these 
considerations.  CRISIS,  sponsored  by  the  USAF  Academy,  has  a  civil  engineering  focus 
(Royer  et  al,  1990).  It  allows  the  graphical  construction  of  different  elements  of  an 
airbase  for  a  two  dimensional,  top-down  view.  CRISIS  is  an  application  layered  on  top  of 
AUTOCAD,  a  sophisticated  Computer-Aided  Design  software  package,  which  sells  for 
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approximately  $4000.  Efforts  are  currently  underway  to  port  CRISIS  to  an  open  systems 
environment,  where  it  will  presumably  be  independent  of  AUTOCAD. 

CRISIS  allows  specification  of  runways,  parking  areas,  and  buildings.  It  also 
provides  the  civil  engineer  with  the  capability  to  flag  bomb  craters,  fires,  and  otter 
problems  around  the  base.  Other  users  can  use  the  Civil  Engineering  data  as  status 
information. 

While  CRISIS  provides  a  good  tool  for  civil  engineers,  there  are  many  facets  of 
planning  for  arrival  of  deploying  units  that  it  does  not  encompass.  Also,  it  currently  lacks 
a  three-dimensional  (3-D)  visualization  of  the  layout  that  is  developed.  Its  interface  is 
very  Computer  Aided  Design  (CAD)-like,  which  may  be  hard  for  the  average  logistics 
planner  to  use.  An  ECLIPSE  BPT  is  envisioned  to  be  a  graphical  application  which  will 
provide  help  in  laying  out  and  evaluating  plans  for  accommodating  deploying  units.  It  will 
provide  capabilities  similar  to  CRISIS  for  runways,  parking  areas,  general  buildings,  and 
emergency  areas.  It  will  also  add  the  capabilities  to  "drag-and-drop"  tent-city  "cells," 
mess  facilities,  and  many  others  previously  mentioned.  These  items  will  be  available  from 
a  tool  bar.  The  planner  will  typically  start  with  a  map  of  the  base  as  it  currently  exists,  and 
choose  relevant  items  from  the  tool  bar  to  place  on  the  map.  In  the  ideal  system,  image 
recognition  techniques  would  enable  the  basic  features  on  the  map  to  be  categorized  and 
stored  as  database  objects.  In  a  less  well-developed  system,  the  user  could  overlay  toolbar 
items  manually  onto  the  scanned-in  map,  photograph,  or  vectorized  drawing.  This  second 
approach  will  be  used  for  items  that  are  not  part  of  the  existing  base  structure. 

For  example,  if  a  deployed  base  receives  notification  that  it  will  soon  be  hosting  24 
additional  F-16s,  plans  need  to  be  made  for  parking  and  sheltering  these  aircraft.  Just  as 
significantly  to  the  planner,  arrangements  must  be  made  for  living  quarters  for  additional 
pilots,  maintenance  crews,  staff,  security  police,  and  so  forth.  If  there  is  not  existing  space 
in  on-base  quarters,  contract  quarters,  or  converted  base  facilities,  tent  cities  will  be 
constructed.  BPT  users  will  select  the  tent  city  icon  from  the  tool  bar  and  drop  it  as  an 
overlay  onto  the  base  map  in  the  desired  location,  where  they  could  subsequently  size  it  to 
fit  the  deployment  needs.  They  will  have  the  ability  to  enter  and  save  attributes  of  each 
item  constructed.  For  a  tent  city,  appropriate  attributes  might  be  number  of  beds,  need  for 
air  conditioning  units,  latrine  facilities,  distance  from  base  perimeter,  distance  from  work 
centers,  and  messing  facilities.  In  a  full  capability  BPT,  planners  will  be  able  to  enter  the 
attributes  for  the  tent  city,  and  the  system  will  query  its  database  knowledge  of  the  base, 
compare  the  specified  attributes,  and  visually  highlight  good-fit  locations  on  the  base.  The 
planner  could  then  locate  the  tent-city  in  one  of  those  locations,  or  override  the 
recommendation  and  locate  it  somewhere  else.  The  BPT  might  also  generate  reports  on 
the  degree  of  suitability  of  possible  sites  specified  by  the  planner,  if  no  sites  completely 
match  the  specified  tent  city  attributes.  This  report  generation  capability  should  be 
implemented  using  intelligent  database  techniques,  discussed  in  more  detail  in  the  section 
on  enabling  technologies.  Essentially,  an  object-oriented  (either  physically  or  logically) 
database  will  contain  the  raw  information  about  the  base.  Between  it  and  the  user- 
selectable  function  to  create  a  tent  city  will  be  a  set  of  rules  that  evaluate  the  user- 
specified  attributes  agmnst  the  raw  data,  to  form  a  complex  query.  Planners  in  this 
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example  are  giving  the  database  a  profile  of  the  kind  of  tent  city  desired,  and  the  database 
determines  whether  it  can  create  one  according  to  rules  regarding  the  profile.  This  type  of 
database  logic  obviously  involves  more  preparation  than  a  conventional  database.  Instead 
of  just  inputting  schema,  the  database  designer  must  input  sets  of  rules  involving  the 
creation,  modification,  selection,  and  deletion  of  objects. 

Capability  Assessor 

The  Capability  Assessor  will  provide  the  ability  to  load  tailored  UTCs,  and  use 
them,  combined  with  known  assets  at  the  deployed  location,  to  perform  simulations  of  unit 
flying  operations.  Scenario  definition  databases  would  exist  for  each  flying  unit  and 
OPLAN  portion  it  was  tasked  to  perform,  describing  expected  sortie  durations  and 
frequencies,  types  and  configuration  of  aircraft  for  different  missions,  attrition,  and 
procedures  for  aircraft  maintenance.  Maintenance  procedures  could  be  recorded  as 
Logistics  Composite  Model  (LCOM)  databases,  since  most  existing  weapon  systems  have 
already  been  documented  in  this  format.  The  Integrated  Model  Development 
Environment  (IMDE)  simulation  environment  (described  briefly  in  Appendix  F)  has 
already  been  modified  to  convert  LCOM  database  networks  into  simulation  programs,  so 
it  will  be  used  to  construct  simulations  using  these  databases  and  the  UTC  listings. 
Results  from  the  simulations  can  be  displayed,  reported,  or  used  to  iteratively  tailor  the 
UTCs,  automatically  running  sensitivity  analyses  on  selected  line  numbers  and  changing 
quantities  as  required.  Results  could  be  used  as  an  SORTS  reporting  tool,  taking  into 
account  the  dynamics  of  logistics  processes  that  are  currently  not  modeled.  The 
simulation  function  will  have  to  be  designed  to  be  at  the  same  level  of  user  sophistication 
as  the  Dynametric  Microcomputer  Analysis  System  (DMAS),  to  assure  its  initial  usability. 
This  type  of  simulation  will  in  general  only  be  used  for  mission-critical  equipment  and 
personnel.  However,  a  library  of  object-oriented  simulations  could  be  constructed  with 
IMDE  which  would  allow  other  parts  of  the  tailored  UTCs  to  be  checked  as  well. 
Simulations  to  validate  medical,  messing,  housing,  and  resupply  operations  could  be 
developed  and  designed  to  take  input  directly  from  the  UTCs  and  a  specified  set  of 
scenario  inputs.  Some  of  these  functions  will  be  adequately  suited  to  smaller,  less 
complex  simulations  than  the  ^rcraft  maintenance  procedures,  and  can  therefore  be  more 
efficiently  modeled  in  stand-alone  simulations.  IMDE  can  be  used  to  develop  the  models, 
and  the  Capability  Assessor  can  offer  the  different  planning  organizations  on  the  base 
network  the  capability  to  choose  from  a  list  of  the  developed  models  to  find  those  relevant 
to  their  planning  needs. 
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CONCLUSIONS 


There  is  clearly  much  dissatisfaction  with  the  current  unit-level  contingency 
planning  tools,  and  a  lot  of  anticipation  for  the  tools  that  will  be  coming  on  line  in  the  next 
year.  The  challenge  of  ECLIPSE,  aside  from  its  technical  aspirations,  is  to  fit  into  frie 
evolving  information  architecture  in  a  way  that  allows  planners  to  use  it  as  an  easily 
accessible  set  of  tools  on  the  network.  Based  on  the  results  of  briefings  to  logistics 
planners  after  the  development  of  the  conceptual  ECLIPSE  components,  there  appears  to 
be  a  good  deal  of  enthusiasm  for  the  ideas  that  have  been  proposed.  In  an  era  when  the 
U.S.  is  sitting  on  the  brink  of  contingencies  all  over  the  world  (Haiti,  Cuba,  Bosnia, 
Korea,  Rwanda,  and  Kuwait,  to  name  a  few)  and  experiencing  sharply  declining  defense 
budgets,  automated  tools  that  can  optimize,  in  practice,  available  resources  are  needed 
immediately.  Technologies  are  maturing  at  a  pace  where  the  ECLiPSE  components  can 
currently  be  prototyped  in  the  open  systems  environment  and  demonstrate  their  ability  to 
aid  the  rapid  deployment  process. 
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ACRONYMS  AND  ABBREVIATIONS 


3-D 

Three-dimensional 

AAFIF 

Automated  Air  Field  Information  File 

AF 

Air  Force 

AFLMA 

Air  Force  Logistics  Management  Agency 

AFLMC 

Air  Force  Logistics  Management  Center 

AFSC 

Air  Force  Systems  Command 

AFSOC 

Air  Force  Special  Operations  Command 

AGE 

Aerospace  Ground  Equipment 

AI 

Artificial  Intelligence 

ALLRS 

Automatic  Lessons  Learned  Recording  System 

AMC 

Air  Mobility  Command 

AMPS 

Automated  Mobility  Processing  System 

API 

Applications  Programming  Interface 

BPT 

Beddown  Planning  Tool 

CALM 

Computer-Aided  Load  Manifesting 

CASE 

Computer-Aided  Software  Engineering 

CBR 

Case-Based  Reasoning 

CGM 

Computer  Graphics  Metafile 

CLI 

Compression  Labs,  Inc. 

CMOS 

Cargo  Movement  &  Operation  System 

COMPES 

Contingency  Operation  Mobility  Planning  &  Execution 
System 

CONUS 

Continental  United  States 

COTS 

Commercial  Off-The-Shelf 

CPU 

Central  Processing  Unit 

CRAF 

Civil  Reserve  Air  Fleet 

CRISIS 

Combat  Readiness  &  Infrastructure  Support  Information 
System 

DISE 

Deployment  Information  and  Support  Environment 

DMA 

Defense  Mapping  Agency 

DMAS 

Dynametric  Microcomputer  Analysis  System 

DOD 

Department  of  Defense 

DKB 

Deployment  Knowledge  Base 

DS 

Direct  Send 

DVE 

Digital  Video  Everywhere 

ECLIPSE 

Enhance  Contingency  Logistics  Planning  and  Support 
Environment 

EM 

Eavesdrop  Mode 

ESCAM 

Enhanced  SORTS  Capability  Assessment  Module 

FEC 

Forward  Error  Correction 

FPS 

Frames  Per  Second 

GCCS 

Global  Command  and  Control  System 

GEOLOCS 

Geographic  Locations 
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GKS 

Graphical  Kernel  System 

HP 

Hewlett-Packard 

IDS 

Integrated  Deployment  System 

IGES 

Initial  Graphics  Exchange  Specification 

IMDE 

Integrated  Model  Development  Environment 

INMARSAT 

International  Maritime  Satellite 

ISAAC 

Integrated  Simulation  Assessment  of  Airbase  Capability 

ISDN 

Integrated  Services  Digital  Network 

JCS 

Joint  Chiefs  of  Staff 

JOPES 

Joint  Operation  Planning  and  Execution  System 

JTF 

Joint  Task  Force 

JULES 

Joint  Universal  Lessons  Learned 

LAN 

Local  Area  Network 

LCOM 

Logistics  Composite  Model 

LLDB 

Lessons  Learned  Database 

LOG-AID 

Logistics  Analysis  to  Improve  Deployability 

LOGDET 

Logistics  Detail 

LOGFOR 

Logistics  Forces 

MAFIS 

Multimedia  Air  Field  Information  System 

MAJCOM 

Major  Command 

MB 

Megabjde 

MCU 

Multipoint  Control  Unit 

MDC 

Maintenance  Data  Collection 

MFEL 

Manpower  Force  Element  Listing 

MTN 

Maintenance  Task  Networks 

NITF 

National  Imagery  Transmission  Format 

ODBMS 

Object-oriented  Database  Management  System 

OPLAN 

Operational  Plan 

OPSMOD 

Operations  Module 

OSE 

Open  Systems  Environment 

PC 

Personal  Computer 

PHIGS 

Programmer’s  Hierarchical  Interactive  Graphics  System 

PM 

Poll  Mode 

QBE 

Query  By  Example 

R&D 

Research  &  Development 

RDBMS 

Relational  Database  Management  System 

RF 

Radio  Frequency 

RPC 

Remote  Procedure  Call 

SAC 

Strategic  Air  Command 

SBSS 

Standard  Base  Supply  System 

SORTS 

Status  of  Resources  and  Training  System 

SPO 

System  Program  Office 

SPORTS 

Second-generation  Portable  Remote  Telecommunications 
System 

SQL 

Structured  Query  Language 

TASC 

The  Analytic  Sciences  Corporation 
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TCP/IP 

Transmission  Control  Protocol/Internet  Protocol 

TPFDD 

Time-Phased  Force  Deployment  Document 

TPFDL 

Time-Phased  Force  Deployment  Listing 

UIC 

Unit  Identification  Code 

UIP 

User  Interface  Prototype 

USAF 

United  States  Air  Force 

UTC 

Unit  Type  Code 

UTC-DTO 

Unit  Type  Code-Development,  Tailoring,  and  Optimization 

WABI 

Windows  Applications  Binary  Interface 

WAN 

Wide  Area  Network 

wees 

Wing  Command  and  Control  System 

WMP 

War  Mobilization  Plan 

WRM 

War  Reserve  Material 

WTI 

Workstation  Technologies,  Inc. 

WWMCCS 

Worldwide  Military  Command  and  Control  System 
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APPENDIX  A 


POTENTIAL  DATA  COLLECTION  MODES  FOR  AUTOMATED 
LESSONS  LEARNED  RECORDING  SYSTEM  (ALLRS) 

Three  potential  ‘hiodes”  for  collecting  deployed  lessons  learned  information  are 
envisioned.  These  are  called  Eavesdrop,  Poll,  and  Direct  Send.  Each  has  potential  applications 
for  obtaining  information  from  a  decentralized  networking  infrastructure  which  will  be  provided 
to  some  extent  by  WCCS  and/or  LOGMOD-B.  The  different  modes  vary  in  the  selectiveness  of 
their  extraction  of  data,  and  correspondingly  in  the  amount  of  information  they  are  required  to 
know  about  other  network  applications.  Each  is  discussed  briefly  below. 

In  the  Eavesdrop  mode  (EM),  ALLRS  will  listen  to  all  traffic  on  the  network  and 
determine  what  to  save  as  significant  lessons  learned  information.  EM  requires  at  least  some 
analysis  of  every  packet  on  the  network,  although  many  may  be  ignored  after  initial  screening 
based  on  sender  address  and  type  of  information  contained  in  the  message.  EM  will  be  the  most 
technically  challenging  mode  of  the  ALLRS  automatic  collection  to  develop,  since  it  requires  low- 
level  network  programming,  a  high  rate  of  processing  of  packets,  and  a  detailed  knowledge  of  all 
potential  WCCS  packets  of  interest.  WCCS  packet  descriptions  are  required  in  order  for  ALLRS 
to  know  which  packets  to  ignore  and  what  parts  of  the  remaining  packets  to  collect,  as  well  as 
where  to  put  the  collected  information  in  the  database.  EM  has  the  advantage  of  requiring  little 
or  no  active  knowledge  of  ALLRS  by  other  WCCS  nodes.  In  the  development  phase  of  ALLRS, 
this  would  be  advantageous  in  not  requiring  modifications  to  WCCS  software  modules  to  make 
them  "ALLRS-aware." 

Poll  mode  (PM)  automatic  collection  provides  the  ALLRS  stations  with  the  capability  to 
query  individual  WCCS  database  nodes  at  a  specified  frequency  for  desired  information.  PM  is 
more  intrusive  into  WCCS  than  EM,  since  it  generates  traffic  on  the  WCCS  network,  and  requires 
processing  time  from  database  servers  on  the  network  to  respond  to  its  queries.  As  an  advantage, 
PM  requires  a  much  lower  processing  rate  on  ALLRS  for  longer  query  intervals.  Only  packets 
from  the  database  queries  need  to  be  analyzed,  and  these  can  be  processed  at  a  client-server  SQL 
level  instead  of  the  network  layer  programming  level  required  for  EM. 

The  use  of  EM  collection  would  be  advantageous  if  a  complete  time  history  of  certain 
parameters  were  desired.  For  example,  the  specific  changes  made  to  the  flying  schedule  might  be 
monitored  to  determine  what  factors  are  most  important  in  day-to-day  scheduling  of  flying 
operations.  Every  time  the  flying  schedule  changes  (takeoff  time,  mission  abort,  pilot  change, 
in-flight  turn,  etc  ),  ALLRS  picks  this  off  the  network  and  records  it.  This  kind  of  time  history 
might  be  useful  as  a  "lesson  learned"  to  the  currently  deployed  unit  as  well,  helping  to  identify 
scheduling  problem  trends  that  might  be  easy  to  correct  if  the  likely  causal  factors  could  be 
pinpointed. 

PM  collection  might  be  more  advantageous  for  parameters  that  can  be  collected  at  a 
coarser  level  of  granularity.  For  example,  a  daily  report  from  the  WCCS  supply  database 
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regarding  parts  availability  might  be  adequate.  The  ALLRS  station  would  automatically  issue  a 
request  to  the  appropriate  WCCS  server  on  a  daily  basis,  asking  it  to  return  the  current  supply 
inventory  status,  or  maybe  just  delta  quantities  from  the  previous  day's  reports.  Depending  on  the 
exact  schema  of  the  WCCS  database,  it  may  be  possible  to  implement  PM  using  standard  SQL 
calls  used  by  other  WCCS  information  requesters,  which  would  not  require  WCCS  software 
modifications  to  accommodate  this  mode  of  ALLRS.  PM  has  the  additional  advantage  of 
allowing  user-customized  collection  schedules  of  user-specified  data  by  any  authorized  user 
capable  of  writing  SQL  queries.  EM  requires  either  a  network  programmer  or  development  of  a 
scripting  language  that  would  effectively  mimic  SQL  functionality.  EM  time  history  data  could  be 
implemented  by  setting  PM  collection  intervals  as  low  as  the  expected  change  times  of  the 
parameter  of  interest.  For  example,  aircraft  availability  could  be  requested  every  15  minutes  and 
probably  provide  all  potentially  interesting  trend  data.  The  tradeoff  is  some  increase  in  network 
traffic  while  lowering  the  processing  demand  on  ALLRS  inherent  in  EM.  An  additional 
disadvantage  of  EM  is  that  as  the  WCCS  Oracle  schema  changes,  the  structure  of  each 
corresponding  client-server  data  packet  will  change  in  a  non-transparent  way,  making  it  more 
difficult  to  accommodate  change  to  ALLRS  to  keep  it  "in-step"  with  WCCS.  Finally,  EM  may 
not  catch  all  changes  desired  to  be  collected,  since  data  entered  locally  to  a  WCCS  database  may 
not  be  sent  across  the  network  if  the  redundant  server  is  not  on-line,  or  if  the  redundant  server 
does  not  record  time  history  data.  An  analysis  of  the  effects  of  the  additional  network  traffic 
generated  by  PM  implementation  should  be  accomplished  to  determine  its  significance. 

A  final  option  exists  that  would  allow  WCCS  stations  to  "push"  data  to  ALLRS.  This 
might  allow  more  flexibility  to  each  WCCS  functional  area  to  specify  for  themselves  which  data 
elements  generated  at  their  station  were  important  and  should  be  captured  in  the  Lessons  Learned 
Data  Base  (LLDB).  This  Direct  Send  (DS)  option  has  some  of  the  advantages  of  the  PM  transfer 
option,  with  the  additional  disadvantage  of  requiring  the  WCCS  development  effort  to  comply 
with  some  interface  control  document  specifying  the  methods  of  interfacing  with  ALLRS. 
Changes  to  ALLRS  could  potentially  require  corresponding  changes  in  WCCS  to  maintain 
capability  and  even  to  avoid  run-time  errors. 

Some  combination  of  EM,  PM,  and  DS  may  be  desirable  to  implement  ALLRS,  with 
different  modes  used  to  satisfy  different  data  requirements. 
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APPENDIX  B 


DESKTOP  VIDEOCONFERENCING  PRODUCTS 

This  appendix  describes  several  desktop  videoconferencing  systems.  Comparisons  are 
made  between  the  different  capabilities  of  the  products,  with  emphasis  on  compatibility  with  other 
systems  and  information-sharing  capabilities.  This  appendix  is  broken  down  into  three  sections: 
Sun,  Macintosh,  and  PCs  running  Microsoft  windows. 

Sun/SunOS 


ShowMe  (V.2.0) 

ShowMe  2.0,  produced  by  SunSolutions,  is  comprised  of  several  separate  packages  that 
provide  a  fiill  set  of  videoconferencing  capabilities.  It  is  based  on  the  Motif  graphical  user 
interface  and  runs  on  SPARC  stations  over  Transmission  Control  Protocol/Intemet  Protocol 
(TCP/IP)  networks. 

Video  capabilities  are  provided  through  ShowMe  Video.  Video  transmit  rates  are 
selectable  by  the  user  up  to  30  frames  per  second.  A  camera  is  mounted  on  each  user's 
workstation.  A  one-way  conference  feature  that  is  also  included  allows  participants  without  a 
Sun  Video  capture/compression  SBus  card  to  receive  video  images. 

ShowMe  Audio  provides  teleconferencing  capabilities.  The  sound  is  played  either  throu^ 
the  computer's  speaker  or  through  headphones. 

ShowMe  SharedApp  allows  conference  members  to  collaboratively  run  software 
applications,  even  if  the  application  is  only  installed  on  one  of  the  involved  systems.  SharedApp  is 
Windows  Application  Binary  Interface  (WABI  compatible;  thus,  it  will  run  any  WABI-supported 
Windows  application  as  well  as  any  X  Windows  System  1 1  application. 

ShowMe  Whiteboard  provides  a  shared  workspace  where  all  users  can  concurrently 
display  images,  annotate  images  with  text,  enter  a  message,  and  so  forth.  Each  user  has  a 
different  colored  "marker"  so  that  it  is  possible  to  distinguish  editions  made  by  different  people. 
Whiteboard  supports  24-bit  images,  so  high-quality  graphics  can  be  displayed.  It  is  also  possible 
to  run  several  \^teboard  sessions  on  a  single  SPARC  computer. 

Unfortunately,  ShowMe  is  not  yet  compatible  with  any  other  videoconferencing  products; 
however,  H.320  compatibility  is  planned  for  a  future  release.  Versions  of  ShowMe  for  Hewlett- 
Packard  and  IBM  workstations,  as  well  as  Intel  platforms  running  Microsoft  Windows  or  Solaris 
X86,  will  be  available  this  year. 


45 


Communique!  (V.3.0) 

With  two  thousand  licensed  seats,  InSoft's  Communique!  is  one  of  the  mainstream 
desktop  videoconferencing  products  available  for  the  Sun.  Communique!  offers  fiill-motion  color 
video,  audio,  file  transferring,  and  text/graphics  exchange  through  a  shared  whiteboard.  The 
number  of  video  conference  attendees  depends  on  hardware  factors  such  as  network  load,  but 
InSoft  says  there  is  a  "logical  limit"  often.  The  software  is  available  both  separately  and  as  part 
of  a  conferencing  kit  that  contains  a  video  board,  a  directional  microphone,  and  a  desktop  video 
camera.  Communique!  has  been  ported  to  SunOS,  HP/UX,  AIX,  and  Solaris  2.3,  and  is  soon  to 
be  ported  to  DEC'S  Alpha  AXP  workstations.  Versions  for  both  Windows  and  Windows  NT  are 
soon  to  be  released.  With  the  PowerPC  coming  out,  InSoft  is  thinking  about  developing  a  version 
for  the  Macintosh. 

Communique!  runs  best  on  a  LAN  or  wide  area  network  (WAN).  ISDN  and  Switched  56 
connections  are  also  possible  through  a  TCP/IP  link. 

CommuniquelTV  is  also  included.  With  this  package,  input  can  be  received  from  VCRs 
and  cameras.  This  allows  users  to  bring  8-  or  24-bit  gray  scale  images  into  the  conference  for 
viewing  and  editing  through  the  shared  whiteboard. 

There  are  also  two  separate  products  available  from  InSoft,  InSync  and  SHARE.  InSync 
dynamically  balances  CPU  and  network  loads,  frame  rates,  compression  ratios  and  sampling  rates 
for  optimal  performance.  InSync  also  allows  users  to  manually  set  the  frame  rate  and 
compression  parameters.  Data  sharing  is  accomplished  by  the  SHARE  package.  The  application 
and  data  are  local  to  one  party,  but  all  parties  can  concurrently  view  and  edit  the  data. 

Communique!  currently  uses  a  proprietary  format  to  transmit  video  and  audio  data,  but 
H.320  compatibility  will  be  available  later  this  year.  Compatibility  does  exist  between  different 
platforms  running  Communique!  Thus,  Communique!  on  a  Sun  SPARCstation  can  be  connected 
with  Communique!  on  a  Windows  PC. 

Application-sharing  is  only  implemented  in  the  UNIX  version,  so  it  is  not  yet  possible  to 
share  applications  from  UNIX  to  Windows  or  Windows  to  Windows.  InSoft  is  working  on  a 
method  to  share  applications  from  the  UNIX  side  to  Windows  running  an  X-Windows  interface 
like  PC  Xview  or  Solaris  X86. 

Another  example  of  InSoft's  commitment  to  cross-platform  functionality  is  the  Digital 
Video  Everywhere  (DVE)  architecture  in  all  its  products.  The  goal  of  DVE  is  complete  hardware 
independence  for  both  audio  and  video.  Another  factor  that  increases  Communique's 
interoperability  is  the  fact  that  InSoft  does  not  build  their  own  boards.  Instead  of  using 
proprietary  hardware,  InSoft  products  support  different  commercially  available  boards.  By  July, 
InSoft  will  have  an  applications  programming  interface  (API)  for  DVE  that  will  allow  third-party 
vendors  to  create  cross-platform  videoconferencing  applications. 
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Paradise  Software  Video  Conferencing  (PSVC) 

PSVC  is  produced  by  Paradise  Software,  Inc.  It  is  strictly  an  audio/video  conferencing 
tool;  therefore,  application  sharing  and  whiteboard  capabilities  are  not  provided.  Users  can  adjust 
frame  speed,  image  quality,  and  window  size  of  the  video  display.  Video  messages  can  be 
recorded  on  the  hard  disk  through  the  UNIX  mail  subsystem  to  accommodate  parties  unable  to 
attend  the  videoconference.  PSVC  does  support  multipoint  conferences. 

TCP/IP  networks  are  used  to  handle  the  connections  between  parties.  Instead  of 
conforming  to  a  standard  such  as  H.320,  PSVC  uses  a  proprietary  format  in  a  similar  way  that 
ShowMe  and  Communique!  do.  Therefore,  only  those  parties  equipped  with  PSVC  can  join  a 
conference. 

At  present,  PSVC  is  only  supported  on  Suns.  Support  for  HP  workstations  will  soon  be 
available,  and  there  are  plans  to  support  the  IBM  RS/6000.  Unfortunately,  Paradise  Software  has 
no  plans  to  support  either  PCs  or  Macintosh  computers. 

Macintosh 


BeingThere  Pro 

Intelligence  at  Large,  Inc.,  produces  BeingThere  Pro.  It  is  a  LAN-based  product  that 
allows  several  parties  to  engage  in  a  videoconference.  It  does  not  directly  support  TCP/IP 
connections  but  will  work  through  a  WAN  extension  for  TCP/IP,  such  as  AppleTalk  Internet 
Router. 


The  software  will  handle  up  to  ten  parties,  but  four  or  five  is  the  maximum  for  acceptable 
performance.  Any  more  than  that  will  cause  the  transmissions  to  be  to  slow,  making  video  and 
audio  annoyingly  choppy.  However,  if  the  machine  is  equipped  with  a  hardware  codec 
(coder/decodeO,  the  number  of  parties  can  be  greatly  increased  and  will  only  be  limited  by 
hardware  considerations. 

The  Macintosh  is  currently  the  only  supported  platform.  Versions  for  Windows  and  the 
PowerPC  are  being  developed.  There  are  no  plans  as  of  yet  for  a  Sun  version,  but  Macintosh  is 
noticing  a  very  large  demand. 

One  drawback  to  this  product  is  the  lack  of  a  shared  whiteboard  and  an  application¬ 
sharing  capability.  Instead,  the  package  supports  file-sharing.  One  party  can  edit  the  data  while 
the  other  parties  can  only  view  the  data.  For  another  party  to  edit  the  data,  it  must  be  sent  to  that 
location  through  a  file  transfer  capability.  The  drawbacks  to  this  approach  include  wasted  time 
and  the  necessity  for  all  parties  to  have  the  appropriate  software  applications  installed  locally. 
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Cameo 


Cameo  is  produced  by  Compression  Labs,  Inc  (CLI).  At  present,  it  only  supports  point- 
to-point  conferences,  so  only  two  parties  can  be  involved  in  a  videoconference.  The  audio  is 
handled  through  a  separate  phone  instead  of  through  a  microphone  and  speaker  attached  to  the 
computer.  Several  different  networks  are  supported,  including  Ethernet,  ISDN,  Switched  56,  and 
analog  phone  lines  using  a  modem.  Cameo  includes  a  shared  whiteboard  and  provides  file 
transfer  capabilities. 

At  present,  there  is  no  interoperability  with  Cameo,  so  a  person  with  Cameo  can  only 
engage  in  a  videoconference  with  another  person  with  Cameo;  however,  plans  exist  to  change 
this.  CLI  is  a  member  of  a  large  consortium  called  Personal  Communications  Systems  (PCS), 
which  was  started  by  Intel  with  the  purpose  of  defining  desktop  video  standards. 

Share  View  3000 

ShareView  3000  is  produced  by  Creative  Labs,  Inc.  ShareView  3000  provides  fiill  video 
and  audio,  an  interactive  whiteboard,  and  true  application-sharing.  The  package  includes  two 
NuBus  cards,  a  color  video  camera,  a  Plantronics  Mirage  headset,  a  telephone  receiver,  and 
software. 

ShareView  3000  will  be  available  for  Windows-based  PCs  in  the  near  future.  It  will  be 
compatible  enough  with  the  Macintosh  version  to  share  video,  audio,  and  whiteboard  capabilities. 
Application-sharing  will  not  be  available  between  the  two  platforms  at  first,  but  Creative  Labs 
does  plan  to  offer  the  capability  in  the  fixture.  ShareView  3000  does  not  support  H.320,  thus  it  is 
incompatible  with  other  systems.  However,  H.320  compliance  should  be  implemented  sometime 
in  1995. 

ShareView  3000  uses  a  single  telephone  line  to  carry  the  video  and  audio  signals.  The 
system  only  allows  point-to-point  conferences,  but  multipoint  capabilities  will  be  available  in  the 
future.  Audio  and  video  clips  can  be  saved  for  later  use.  ShareView  3000  allows  a  user  to  store 
ten  minutes  of  video  data  on  a  single  floppy  disk. 

ShareView  3000  has  some  additional  features.  ShareView  Business  Cards  allow 
ShareView  users  to  easily  exchange  photos  or  company  logos.  There  is  an  integrated  phone  book 
that  stores  information  about  contacts.  Incoming  and  outgoing  calls  are  recorded  by  an  automatic 
call  log  which  allows  users  to  review  call  statistics  and  conduct  time-based  billing. 

Connect  918 

NUTS  Technologies,  Inc.,  produces  Connect  918.  Up  to  three  parties  can  participate  in  a 
videoconference.  Connect  918  supports  the  H.320  videoconferencing  standard:  thus, 
conferencing  with  any  other  system  that  is  H.320-compatible  should  be  possible.  Connect  918 
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supports  ISDN  and  LAN  connections,  and  will  support  Switched  56  and  analog  lines  in  the 
future. 


Capabilities  of  Connect  918  include  screen-sharing,  file  transfer,  shared  whiteboard,  and 
video/audio  recording  and  playback.  Application-sharing  is  not  possible.  Instead,  Connect  918 
uses  a  file  transfer  technique  similar  to  the  one  used  by  BeingThere  Pro. 

There  are  versions  for  both  the  Macintosh  and  Microsoft  Windows.  If  a  Macintosh  and  a 
Windows  PC  are  both  equipped  with  Connect  918,  they  have  access  to  fiill  video,  audio,  and  the 
shared  whiteboard.  The  Windows  version  is  set  to  be  released  in  June. 

Visit  Video 

Visit  Video  is  produced  by  Northern  Telecom,  Inc.  It  offers  full  video  and  audio 
conferencing  capabilities  as  well  as  a  shared  whiteboard.  Visit  uses  either  ISDN  or  Switched  56 
communication  lines.  Connectability  through  LANs  and  analog  lines  will  be  available  in  the 
future.  Currently,  it  is  a  point-to-point  system,  but  an  eight-party  bridge  will  be  available  in  the 
future.  There  are  no  application-sharing  capabilities,  but  Visit  does  allow  file  exchanging. 

One  attractive  feature  of  Visit  is  its  compatibility.  There  are  versions  for  the  Macintosh 
and  Windows,  and  these  versions  are  totally  compatible  with  each  other.  Visit  currently  complies 
with  the  H.261  standard  (a  part  of  H.320)  and  will  comply  with  H.320  in  the  future. 

Microsoft  Windows 

AT&T  Telemedia  Personal  Video  System 

The  Telemedia  Personal  Video  System  seems  to  be  one  of  the  best  videoconferencing 
products  available  for  the  PC.  In  a  review  of  PC  videoconferencing  products,  including 
PictureTel's  LIVE  PCS  100  and  Northern  Telecom's  Visit  Video  (both  of  which  are  described 
later),  PC  Magazine  listed  the  Telemedia  Personal  Video  System  as  the  Editor's  Choice. 

The  system  currently  operates  over  ISDN  and  Switched  56  lines.  LAN  connectivity  wdll 
be  available  near  the  end  of  1994.  By  itself,  the  system  only  allows  point-to-point  conferences. 
However,  multipoint  functionality  is  available  through  a  separate  Multipoint  Control  Unit  (MCU). 

This  system  is  currently  the  only  Windows  videoconferencing  product  that  provides  true 
application-sharing.  Only  two  parties  can  share  an  application,  even  if  an  MCU  is  used. 
Multiparty  application-sharing  through  an  MCU  should  be  available  in  the  future.  In  addition,  the 
system  also  provides  an  interactive  whiteboard  and  a  file  transfer  capability.  The  system  is  fiilly 
compliant  with  the  H.320  videoconferencing  standard. 
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PictureTel  LIVE  -  PCS  100 


PictureTel  is  one  of  the  leading  companies  in  the  videoconferencing  industry.  Revenues  in 
1992  reached  $141  million,  and  the  company  has  approximately  45  percent  of  the  market. 

LIVE,  or  PCS  100,  provides  full-color  video  and  full  audio  videoconferencing  capabilities. 
The  camera  is  designed  to  mount  on  top  of  a  monitor  or  on  a  separate  swivel  stand.  The  stand  is 
very  useful  when  displaying  documents.  The  camera  is  turned  to  face  downward,  allowing  the 
user  to  display  documents  simply  by  placing  them  under  the  camera.  Audio  is  handled  through  a 
separate  speakerphone,  although  headsets  are  available. 

LIVE  operates  over  ISDN  or  Switched  56  connections.  A  multipoint  bridge  is  available 
to  allow  several  parties  to  participate  in  a  conference.  LIVE  also  offers  shared  whiteboard  and 
file  transfer  capabilities. 

PictureTel  offers  real-time  application-sharing  through  its  LIVE  Share  add-on  product. 
This  product  provides  certain  capabilities  that  other  application-sharing  products  do  not  have. 
First,  bidirectional  application-sharing  allows  both  parties  to  simultaneously  share  separate 
applications.  With  remote  control  application-sharing,  a  remote  site  can  invoke  an  application  on 
another  system,  even  when  that  computer  is  not  in  use.  Lastly,  LIVE  Share  allows  users  to 
simultaneously  share  multiple  applications. 

LIVE  is  one  of  the  most  compatible  and  upgradable  of  the  videoconferencing  products.  It 
is  fully  compliant  with  the  H.320  standard,  allowing  LIVE  to  connect  with  any  competitive 
system  that  also  supports  H.320.  Also,  LIVE  can  easily  connect  with  PictureTel's  room-based, 
group  videoconferencing  systems. 

In  Vision  VideoConferencing  for  Windows 

Videoconferencing  for  Windows  is  a  software-only  product  designed  to  operate  with 
i750-based  Digital  Video  Interface  (DVI)  video  boards.  It  is  a  LANAVAN-based  product,  and  is 
one  of  the  few  products  for  Windows  that  support  TCP/IP  and  IPX  connections.  All  hardware, 
such  as  the  camera,  microphones,  speakers  and  video  cards,  must  be  purchased  separately. 

Application  sharing  is  not  supported  as  of  yet.  However,  documents  may  be  shared  via  an 
integrated  product  called  Talk  Show  from  Future  Labs  (not  to  be  confused  with  the  Talkshow 
videoconferencing  product  bffered  by  Workstation  Technologies,  Inc.,  described  later).  This 
product  provides  shared  wljiiteboard  and  file  transfer  capabilities.  Talk  Show  should  support 
application  sharing  by  the  enji  of  this  year. 

The  product  is  currently  only  a  LAN/WAN  system.  Connections  through  ISDN  or 
SA\itched  56  lines  are  possible,  but  only  if  they  reside  on  another  node  on  the  network.  By 
September  1994,  In  Vision  will  support  direct  connection  to  ISDN,  Switched  56,  and  analog  lines. 
The  September  release  will  also  offer  H.320  compatibility. 
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The  system  only  offers  point-to-point  connections.  However,  the  next  release  will  ofiEer 
point-to-multipoint  connections.  This  means  that  person  A  can  concurrently  connect  with  persons 
B  and  C,  but  B  and  C  can  only  connect  with  person  A. 

Currently,  Microsoft  Windows  is  the  only  supported  platform.  However,  In  Vision  plans 
to  develop  a  Macintosh  version  which  should  be  available  sometime  in  1995. 

VTEL  115 

The  VTEL  115  is  a  complete  desktop  videoconferencing  system  that  includes  a  486  PC, 
15-inch  monitor,  VTEL's  DeskMax  cardset,  speaker,  camera  with  integrated  microphone,  and 
software.  A  separate  document  camera  is  available  for  viewing  documents  or  3-D  objects. 

The  VTEL  115  operates  over  either  ISDN  or  Switched  56  connections  and  can  achieve 
data  rates  of  up  to  384  Kbps.  VTEL  is  working  on  a  LAN  and  TCP/IP  capability.  The  system  is 
compatible  with  other  videoconferencing  systems  which  support  H.261. 

One  advantage  of  the  VTEL  115  is  the  capability  for  application-sharing.  This  year, 
VTEL  will  integrate  a  commercially  available  collaborative  computing  program  into  the 
videoconferencing  system.  This  will  make  VTEL  one  of  the  very  few  Windows-based  products 
that  support  application  sharing. 

Multipoint  videoconferencing  is  supported  by  a  separate  product,  the  MCU-II  (multipoint 
control  unit).  It  is  initially  configured  for  eight  ports,  but  it  can  support  up  to  twenty.  Without 
the  MCU-n,  the  VTEL  115  only  supports  point-to-point  conferences. 

A  software-controlled  video  camera,  called  SmartCam,  is  available  separately.  The 
SmartCam  provides  features  such  as  pan,  tilt,  zoom,  eight  preset  positions,  and  image  adjustment 
capabilities  for  higher  image  quality. 

VTEL  also  offers  other  models,  including  the  VTEL  117,  which  is  identical  to  the  VTEL 
115  except  that  it  comes  with  a  17-inch  monitor. 

Talkshow 

Workstation  Technologies,  Inc.  (WTI),  produces  Talkshow,  a  desktop  videoconferencing 
system  that  is  available  for  Windows,  Macintosh,  and  the  PS/2.  Video  is  supported  though  a 
camera  mounted  on  top  of  the  monitor,  and  audio  is  handled  through  a  speakerphone. 

Talkshow  is  fully  compatible  across  the  three  supported  platforms.  It  is  currently 
compliant  with  H.261,  and  will  be  compliant  with  H.320  sometime  in  1995.  Talkshow  provides 
an  interactive  whiteboard. 
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Talkshow  operates  over  Switched  56  and  analog  lines.  ISDN  communication  will  be 
supported  in  July  1994.  WTI  has  just  started  beta  testing  an  inband  audio  capability  that  will 
allow  transmission  of  both  video  and  audio  data  on  a  single  line. 

Talkshow  is  currently  a  point-to-point  system.  WTI  plans  to  offer  a  multipoint 
videoconferencing  capability  in  1995. 


Summary 

The  best-case  scenario  would  be  the  capability  to  run  foil  video,  audio,  a  shared 
whiteboard,  and  true  application-sharing  in  a  multipoint  conference  regardless  of  the  hardware 
platforms  used.  Unfortunately,  desktop  videoconferencing  is  such  a  new  technology  that  all  the 
desired  capabilities  are  not  available  in  one  system. 

At  present,  the  H.320  standard  is  the  only  way  that  cross-platform  videoconferencing  is 
possible.  Since  there  are  no  packages  that  are  compatible  with  every  platform,  using  different 
H.320-compliant  packages  for  each  platform  seems  to  be  the  only  way  to  achieve  cross-platform 
videoconferencing.  However,  the  H.320  standard  is  only  designed  for  video  and  audio  data,  so 
there  are  no  guidelines  that  specify  how  to  implement  capabilities  such  as  shared  whiteboards  or 
application-sharing.  As  stated  in  the  previous  sections,  there  are  products  such  as  ShareView 
3000  and  Connect  918  that  are  built  for  different  platforms.  These  packages  provide  for  cross¬ 
platform  video  and  audio,  and  in  some  cases  a  shared  whiteboard.  Unfortunately,  there  are  no 
packages  that  provide  cross-platform  application-sharing. 

Table  B-1  depicts  a  visual  comparison  between  the  packages  discussed.  The  shaded  areas 
show  which  functions  are  available  for  each  system.  Only  those  capabilities  that  were  available  at 
the  time  of  this  publication  are  indicated. 

InSoft's  Communique!  seems  to  be  a  good  candidate  for  UNIX-based  systems.  It 
provides  for  multipoint  conferencing,  a  shared  whiteboard,  and  true  application-sharing  as  long  as 
the  parties  are  operating  under  supported  UNIX  platforms.  A  Windows  version  will  be  available 
that  is  compatible  (except  for  application  sharing)  with  the  UNIX  systems.  Also,  H.320 
compliance  will  be  available  this  year. 

SunSolutions'  ShowMe  is  also  a  good  possibility.  It  provides  all  the  desired  functionality 
for  UNIX-based  systems;  however,  it  seems  to  be  a  bit  behind  Communique!  in  compatibility. 
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$3270  single  user 
$8430  three  users 


$2495  single  user 
$595  for  SHARE 


$995  single  user 
$29,850  50  node  network 


$599  single  user 
$499/user  (10  or  more) 


$1499  LAN  or  analog,  $2500 
for  ISDN  or  SW  56 


$3999  single  user 


$5899  ISDN.  $4299  LAN 


Approx.  $5000  for  both  MAC 
and  PC  versions 


$5995  with  486  PC 
app.  $92,500  8  port  MCU 


$5995  single  user,  $92,500  8- 
port  MCU 


$995  software  only 


$14,950  VTEL 115 
$90,000  8-port  MCU-II 


$199  software  only  1  user 
approx.  $2700  whole  pkg. 


Table  B-1 

Comparison  of  Videoconferencing  Products 


ShareView  3000  seems  to  be  one  of  the  more  promising  products  for  Macintosh  because 
it  offers  full  video  and  audio,  a  shared  whiteboard,  and  true  application-sharing.  A  Windows 
version  will  be  released  shortly  that  is  compatible  except  for  the  application-sharing.  Two 
drawbacks  of  ShareView  3000  are  the  lack  of  multipoint  conferencing  and  H.320  compatibility; 
however,  both  will  be  supported  in  the  future. 

Connect  918  also  seems  to  be  a  viable  candidate.  It  operates  over  ISDN  or  LAN  lines  and 
provides  H.320  compatibility.  It  will  soon  allow  for  videoconferencing  between  Windows  and 
Macintosh  platforms.  Unfortunately,  application-sharing  is  not  supported  and  a  videoconference 
is  limited  to  three  parties. 

For  Windows  machines,  the  AT&T  Telemedia  Personal  Video  System  is  an  extremely 
strong  candidate.  It  provides  all  the  necessary  functionality  such  as  application-sharing, 
interactive  whiteboard,  file  transferring,  and  H.320  compatibility.  PictureTel's  LIVE  also  seems 
to  be  a  good  choice.  It  is  fully  compliant  with  H.320,  making  it  one  of  the  more  compatible 
systems  available.  LIVE  provides  fiill  video,  audio,  a  shared  whiteboard,  and  application-  sharing. 
The  VTEL  115  will  soon  support  application-sharing,  but  VTEL  will  only  sell  the  entire  system, 
including  the  computer,  as  one  unit.  The  VTEL  1 15  is  also  not  fixlly  H.320-compliant.  Of  all  the 
systems  examined.  In  Vision's  VideoConferencing  for  Windows  is  the  only  one  that  supports 
TCP/IP  connections. 

Color  video,  audio,  and  the  capability  to  run  across  different  networks  and  phone  lines 
seem  to  be  pretty  standard  among  most  of  the  products  examined.  Multipoint  conferencing, 
application-sharing  and  cross-compatibility  seem  to  be  causing  the  most  problems.  Most  products 
that  do  not  currently  offer  these  capabilities  will  offer  them  in  the  future.  However,  the  products 
that  offer  the  major  capabilities  today  have  a  big  advantage  over  the  ones  that  will  in  the  fiiture. 
By  the  time  some  companies  are  announcing  the  new  capabilities,  the  other  ones  will  have  already 
worked  out  most  of  the  bugs. 

Technology  has  just  not  advanced  to  the  point  where  fiilly  functional,  cross-compatible 
systems  are  available.  However,  the  desktop  videoconferencing  industry  is  very  competitive, 
which  will  force  vendors  to  provide  the  highest  quality  products  with  the  most  functionality.  It 
will  not  be  long  before  the  perfect  systems  are  on  the  market.  Until  then,  customers  must  decide 
which  of  the  different  capabilities  are  the  most  important  and  select  the  product  which  best 
provides  the  desired  functionality. 
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APPENDIX  C 


SATELLITE  COMMUNICATIONS 

MAFIS  requires  a  data  communication  methodology  that  provides  global  coverage,  even 
in  remote  areas  where  telephone  lines  do  not  exist.  Therefore,  satellite  communications  are 
necessary.  There  are  many  different  satellite  systems,  but  the  one  that  is  best  suited  for  MAFIS  is 
called  the  International  Maritime  Satellite  (INMARSAT). 

The  INMARSAT  network  began  as  a  ship-to-shore  communications  system.  It  has  now 
grown  to  be  one  of  the  largest  commercial  and  military  satellite  communication  systems  in  use. 
Figure  C-1  shows  how  an  INMARSAT  connection  is  established  between  a  remote  site  and  a 
central  location.  The  remote  site  uses  a  portable  terminal  to  communicate  with  a  satellite.  The 
satellite  then  connects  with  one  of  several  ground  stations  around  the  world,  usually  the  one 
closest  to  the  central  location.  A  landline,  such  as  a  telephone  line,  is  then  used  to  connect  the 
ground  station  with  the  central  location.  If  security  is  needed,  an  encryption  device  such  as  an 
STU-III  can  be  used  at  each  end  before  any  data  is  transmitted. 

There  are  four  types  of  INMARSAT  connections.  INMARSAT-A  is  the  one  generally 
used.  It  offers  high-quality  voice  and  high-speed  fax/data  transmissions.  The  cost  for  a  terminal 
is  $30,000  to  $40,000,  and  the  service  cost  is  $7  to  $10  per  minute.  INMARSAT-C  is  cheaper 
($8,000  to  $15,000  for  a  terminal),  but  it  can  only  send  data  or  messages.  There  are  no  voice 
capabilities,  and  transmission  speeds  are  low.  INMARSAT-M  offers  voice  transmission,  but  the 
quality  is  lower  than  INMARSAT-A.  An  INMARSAT-M  terminal  costs  $15,000  to  $25,000,  and 
service  costs  run  $4.00  to  $5.50  per  minute. 

INMARS AT-B  is  a  direct  successor  of  INMARSAT-A  and  is  the  method  most  applicable 
to  the  MAFIS  system.  Transmission  speeds  up  to  64  kbit/sec  are  available,  and  services  at  256 
and  384  kbit/sec  will  be  available  in  the  future.  The  64  kbit/sec  capability  provides  for  up  to  11 
digital  voice  channels  or  20  data  channels  over  a  single  terminal.  It  is  possible  to  conduct 
videoconferences  over  this  connection,  and  normal  video  data  can  be  transmitted  at  30  frames  per 
second.  Group  4  faxes  can  be  sent  at  three  seconds  per  page. 

INMARSAT-B  is  cheaper  than  INMARSAT-A.  The  cost  of  a  terminal  is  $35,000,  and 
service  costs  run  $4  to  $7  per  minute.  An  INMARSAT-B  terminal  averages  100  kilograms,  and 
the  size  of  the  antenna  (diameter  and  height)  is  approximately  0.9  meters  (Brunstrom,  1993). 
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Figure  C-1 

Sample  International  Marine  Satellite  (INMARSAT)  connection 


APPENDIX  D 


SPORTS  AND  IMAGEHAWK 

The  Second-generation  Portable  Remote  Telecommunications  System  (SPORTS)  is  a  PC- 
based  system  that  allows  users  to  acquire,  process,  and  transmit  textual  and  graphical  information 
to  other  computer  systems.  The  system  utilizes  commercial  off-the-shelf  hardware,  and  there  are 
versions  for  both  DOS  and  Windows.  SPORTS  operates  on  any  386  or  higher  computer, 
including  both  desktops  and  portables.  SPORTS  is  certified  as  being  compliant  with  the  National 
Imagery  Transmission  Format  (NITF)  1.1  standard. 

The  user  interface  was  designed  for  ease-of-use  in  high-stress  environments.  SPORTS 
supported  Operations  Desert  Shield  and  Desert  Storm,  and  is  used  daily  by  Special  Forces. 

SPORTS  offers  a  large  set  of  image  processing  capabilities.  It  can  capture  and  display  8- 
bit  grayscale  and  16/24-bit  color  images  from  a  video  source  such  as  a  video  camera,  digital 
camera,  still  video  player,  VCR,  or  scanner.  The  images  can  be  cropped  and  compressed,  and 
subsets  of  images  can  be  stored  on  the  system.  Users  can  zoom,  enhance,  and  annotate  images. 
The  system  can  even  measure  the  two-dimensional  lengths  of  objects  in  an  image. 

SPORTS  also  includes  an  integrated  word  processing  package  which  allows  users  to 
create  and  edit  text  files. 

The  system  can  receive  and  transmit  a  queue  of  different  file  types  (compressed  images, 
word  processing  documents,  facsimile  messages)  over  several  military  and  commercial  circuits: 

•  UHF  SATCOM,  INMARSAT,  TRITAC/TACSAT  satellites; 

•  KY-57,  KY-68,  KG-84A/C,  Sunburst  cryptos; 

•  Kodak  Berkeley  Research  86SC  Forward  Error  Correction  (FEC)  device; 

•  STU-III  secure  telephone; 

•  Cellular  phone/modem;  and 

•  Wireline,  PBX  (e.g.,  SL-100),  public  switched  telephone  network. 

SPORTS  also  has  the  capability  to  capture  and  transmit  video  over  a  9600-baud  secure 
phone  line.  Current  performance  is  limited  to  5  frames  per  second  (FPS),  but  the  system  will  be 
improved  to  accommodate  15  FPS. 

The  ImageHawk  system  is  a  portable  data  collection  and  transmission  system.  The  system 
includes  a  486SX/25  MHz  Notebook  PC,  digital  still  camera,  cellular  modem,  and  an  auxiliary 
power  supply.  All  components  fit  into  a  specially  designed  briefcase  for  ease  of  transportation. 
The  system  operates  under  Microsoft  Windows. 
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The  system  was  designed  to  allow  for  the  easy  transmission  of  data  between  a  home  base 
and  a  remote  site.  Documents  and  graphics  can  be  scanned  at  the  home  base  and  transmitted  to  a 
field  crew.  The  remote  site  can  use  the  digital  camera  to  capture  images  and  send  them  to  either 
the  home  base  or  another  remote  site.  Likewise,  a  remote  site  can  create  and  transmit  text 
documents.  The  software  will  also  enhance  images  to  reveal  obscured  details. 

There  are  several  options  available  for  the  ImageHawk.  The  user  can  include  a  video 
camcorder  and  frame  grabber,  scanner,  video  printer,  and  an  integrated  cellular  phone/modem. 
For  added  communication  ability,  a  radio  hookup  or  a  portable  satellite  terminal  hookup  is 
available.  An  image  enhancement  algorithm  is  available  for  underwater  applications.  The  ability 
to  view  up-to-the-minute  weather  patterns  and  forecasts  at  a  remote  site  is  possible  through  an 
add-on  product  called  WEATHER  for  Windows. 

In  the  future,  the  ImageHawk  system  will  be  able  to  record,  transmit,  and  play  back  video 
and  audio  clips.  Also,  an  integrated  positioning/mapping  capability  will  be  added. 
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APPENDIX  E 

CASE-BASED  REASONING 

This  appendix  provides  an  explanation  of  the  CBR  technology.  Also  included  are  a 
comparison  of  CBR  and  other  AI  techniques,  and  several  examples  of  how  CBR  has  been  used  in 
real-world  applications. 


CBR  Explained 

CBR  is  an  AI  technique  that  catalogs  previous  experience  into  separate  cases.  When 
presented  with  a  problem,  the  CBR  system  searches  the  database  for  cases  that  are  similar.  If  a 
case  is  found  with  exactly  the  same  characteristics  as  the  new  problem,  the  solution  should  also  be 
the  same.  However,  this  rarely  happens.  Instead,  the  system  presents  several  cases  that  match  the 
new  problem  as  closely  as  possible.  Given  the  solutions  of  the  other  cases,  the  user  will  develop  a 
solution  to  the  new  problem.  The  new  problem  and  its  solution  are  then  added  to  the  database  as 
a  new  case.  The  above  process  is  actually  a  series  of  five  steps;  representation,  indexing,  storage 
and  retrieval,  adaptation,  and  leaming/generalization  (Barletta,  1991). 

Representation 

The  first  step  in  developing  a  CBR  system  is  to  determine  how  a  case  is  to  be  represented. 
This  initial  design  phase  is  generally  a  coordinated  effort  between  users,  managers  and  system 
developers.  The  structure  of  the  database,  including  a  list  of  attributes  used  to  describe  each  case, 
is  developed.  Standards  are  also  determined  that  specif  which  words  will  be  used  to  describe 
problem  features,  which  features  will  be  used  to  index  cases,  and  how  new  cases  will  be  authored. 

The  simplest  case  will  be  a  list  of  attributes  that  lead  to  a  specific  outcome.  However,  a 
CBR  system  with  this  design  will  not  be  very  powerful.  A  better  method  is  to  represent  a  case  as 
a  connected  set  of  subcases  that  model  the  situation.  For  example,  instead  of  modeling  a  car  as 
only  a  list  of  characteristics,  it  can  be  modeled  with  a  small  list  of  characteristics  and  a  collection 
of  subcases  that  each  model  a  specific  part  such  as  the  braking  system,  chassis,  suspension, 
electrical  system,  and  so  forth.  This  approach  provides  an  object-oriented  structure  to  the 
database  design  and  adds  a  great  deal  more  power  to  the  CBR  system. 

Indexing 

The  second  step,  case  indexing,  provides  a  way  to  rapidly  determine  when  a  stored  case  is 
considered  relevant  to  the  current  problem.  There  are  four  methods  used  to  index  cases;  nearest 
neighbor,  inductive,  knowledge-guided,  and  a  combination  of  the  three. 

The  nearest  neighbor  approach  is  the  easiest  to  implement.  It  indexes  cases  based  on  a 
weighted  sum  of  features  in  the  input  problem  that  match  stored  cases.  In  its  simplest  form,  each 
attribute  is  weighted  equally;  thus,  a  case  that  matched  the  input  problem  on  seven  attributes  is 
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preferred  over  a  case  that  matches  on  six.  However,  some  attributes  may  be  more  important  than 
others.  This  is  implemented  by  giving  stronger  weights  to  the  more  important  attributes.  For 
example,  consider  a  $6,000  1982  station  wagon.  If  a  car's  body  style  is  more  important  than  price 
or  age,  then  a  $13,000  1992  station  wagon  will  match  more  closely  than  a  $6,000  1982  sedan. 
The  nearest  neighbor  approach  works  well  when  the  retrieval  goal  is  not  well-defined  or  there  are 
only  a  few  cases  in  the  database.  The  biggest  drawback  of  the  nearest  neighbor  approach  is  that  it 
is  dmost  impossible  to  determine  a  single  set  of  weights  that  will  determine  the  best  matching 
cases  for  every  input  problem.  The  importance  of  certain  attributes  may  be  heavily  dependent  oa 
the  values  of  other  attributes.  This  would  mean  that  almost  every  input  case  should  have  its  own 
set  of  attribute  weights. 

An  inductive  indexing  approach  is  very  useful  when  there  are  a  very  large  number  of  cases 
in  the  database.  The  system  examines  each  case  to  determine  which  attributes  best  discriminate 
between  different  outcomes.  The  cases  are  then  arranged  with  respect  to  these  induced  features, 
thereby  structuring  the  database  so  that  the  time  necessary  to  find  matching  cases  is  minimized. 
This  approach  works  best  when  the  case  outcomes  are  well-defined  and  there  are  a  large  number 
of  cases.  The  major  drawback  of  this  approach  is  that  it  may  take  a  substantial  amount  of  time  to 
perform  the  induction  and  database  structuring.  Fortunately,  this  only  needs  to  be  done  at  the 
beginning  and  at  certain  intervals  as  cases  are  added  to  the  database. 

The  knowledge-guided  approach  uses  existing  knowledge  about  each  case  to  determine 
which  features  are  important  for  retrieving  the  case.  This  is  similar  to  applying  an  expert  system 
because  the  knowledge  is  incorporated  into  the  database  in  the  form  of  a  rule-based  domain 
model.  This  approach  works  well  when  there  is  enough  information  about  each  case  to 
sufficiently  explain  the  outcome.  However,  as  the  range  of  attributes  increases,  it  becomes  more 
difficult  to  establish  a  set  of  rules  to  perform  the  indexing.  The  knowledge-guided  approach  is 
generally  applied  in  combination  with  other  indexing  techniques  to  overcome  this  disadvantage.  It 
is  still  beneficial  because  there  is  almost  always  some  useful  indexing  information  in  some  cases, 
just  not  all  of  them. 

Storage  and  Retrieval 

The  main  goal  of  case  retrieval  is  to  return  the  most  similar  past  case  or  cases  that  are 
relevant  to  the  input  problem.  The  manner  in  which  cases  are  stored  in  the  database  can  greatly 
affect  the  efficiency  with  which  the  cases  are  retrieved.  Most  case-memory  structures  fall 
between  two  different  methods,  associative  and  hierarchical.  In  associative  retrieval,  each  feature 
of  a  case  is  indexed  independently  of  all  other  features.  This  approach  is  useful  when  a  single 
database  is  being  used  for  several  retrieval  tasks.  The  hierarchical  approach  entails  organizing 
case  features  into  a  general-to-specific,  tree-like  concept  structure.  When  the  retrieval  task  is 
well-defined,  the  hierarchical  approach  is  best  because  retrieval  time  is  much  less  than  that  of 
associative  methods. 


Adaptation 


The  goal  of  case  adaptation  is  to  take  the  best  retrieved  case  and  transform  it  to  meet  all 
of  the  input  situation's  needs.  Many  CBR  systems  incorporate  adaptation  rules  to  automatically 
adapt  stored  cases  for  specific  problem  domains.  Pieces  of  existing  cases  can  also  be  used  to 
adapt  the  retrieved  case.  This  approach  is  useful  when  it  is  difficult  to  develop  enough  rules  to 
perform  the  adaptation.  In  many  cases,  complete  adaptation  cannot  be  accomplished.  It  is  then 
up  to  the  user  to  provide  the  rest  of  the  necessary  information. 

Learning/Generalization 

Each  adapted  case  is  added  to  the  database  to  be  used  in  future  comparisons.  Therefore, 
the  longer  a  CBR  system  is  used,  the  greater  the  likelihood  that  an  exact  match  of  an  input 
problem  will  be  found.  The  need  for  adaptation  then  diminishes.  Also,  as  the  database  becomes 
large,  generalization  can  be  used  to  develop  prototype  cases  that  meet  the  feature  requirements 
for  specific  case  classes.  These  prototypical  cases  are  added  to  the  database  along  with  the  real 
cases  and  are  accessed  in  the  same  manner.  This  allows  the  CBR  system  to  recognize  and  exploit 
hypothetical  situations  that  can  be  used  to  improve  the  system's  accuracy  in  the  long  run. 

Comparisons  Between  Case-Based  Reasoning  (CBR)  and 
Other  Artificial  Intelligence  Techniques 

Statistical  pattern  recognition  has  been  successfully  used  for  many  years  to  analyze  and 
classify  data.  However,  the  basis  behind  this  techsiique  is  the  use  of  mathematical  equations.  This 
method  is  therefore  limited  to  processing  numerical  data  only.  Another  limitation  is  that  the 
equations  themselves  provide  the  only  explanation  of  the  analysis  results. 

Neural  networks  are  very  adept  at  analyzing  large  amounts  of  data.  They  are  designed  to 
handle  situations  never  before  encountered,  providing  that  they  are  trained  correctly.  They  are 
also  very  good  at  analyzing  data  that  is  incomplete  or  contains  errors.  However,  neural  networks 
suffer  fi'om  the  same  disadvantages  as  statistical  pattern  recognition  methods.  They  are 
mathematical  in  nature,  so  only  numerical  data  can  be  processed.  Also,  the  weights  between  a 
neural  network's  nodes  provide  the  only  explanation  for  results.  These  weights  are  just  a 
collection  of  numbers,  so  the  information  that  can  be  gathered  fi'om  them  is  severely  limited. 
Lastly,  the  performance  of  a  neural  network  is  heavily  dependent  on  how  it  is  designed,  namely 
how  many  layers  the  network  has  and  how  many  nodes  are  in  each  layer.  The  best  way  to  design 
a  neural  network  still  remains  unclear. 

Rule-based  expert  systems  are  very  powerful  at  solving  problems  with  clear-cut  solutions. 
The  main  bottleneck  in  developing  expert  systems  is  the  generation  of  the  rule  base.  Expert 
systems  are  also  very  difficult  to  maintain.  As  new  data  is  made  available,  new  rules  must  be 
added.  This  is  not  a  simple  task  because  the  new  rules  must  be  meticulously  integrated  into  the 
existing  rule  base.  Also,  great  care  must  be  taken  to  ensure  that  rules  do  not  contradict  one 
another.  Like  the  previous  two  techniques,  expert  systems  lack  the  ability  to  sufficiently  explain 
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their  results.  All  an  expert  system  can  do  is  list  the  chain  of  rules  followed  to  achieve  a  given 
result.  In  simple  cases,  this  is  probably  enough.  However,  the  real  explanation  may  get  lost  ia  a 
substantially  long  list  of  rules. 

The  case-based  methodology  offers  several  advantages  that  are  not  present  in  other  AI 
techniques.  First,  the  results  obtained  from  a  CBR  system  can  easily  be  explained.  A  set  of  rules 
generated  by  the  indexing  process  can  be  used,  but  they  are  only  as  useful  as  the  rules  reported  by 
an  expert  system.  The  example  cases  retrieved  by  the  CBR  system  provide  more  important 
information  about  the  analysis  results.  If  an  obvious  result  cannot  be  determined,  the  user  can 
examine  the  example  cases  to  assist  in  determining  a  solution. 

Another  advantage  of  CBR  systems  is  that  they  do  not  exclusively  rely  on  numerical  data. 
Other  types  of  information  (including  images,  sound,  free-form  text  and  others)  can  be  included  in 
a  case.  It  may  not  be  possible  for  the  CBR  system  to  use  this  type  of  information  to  obtain 
results.  However,  this  type  of  information  may  be  invaluable  to  the  user  when  a  comparison 
between  past  cases  and  the  current  problem  must  be  made  manually. 

When  pieces  of  data  are  missing  from  the  input  set,  other  techniques  may  produce 
unreliable  results.  When  a  CBR  faces  incomplete  data,  it  simply  generates  a  larger  number  of 
possible  solution  cases.  The  user  can  then  determine  if  supplying  additional  data  will  narrow  the 
list. 


One  of  the  biggest  advantages  of  CBR  systems  is  the  ease  of  maintenance  and  expansion. 
As  mentioned  above,  adding  rules  to  an  expert  system  can  be  a  very  difficult  process.  Adding 
information  to  a  pattern-recognition  system  may  involve  modifying  the  underlying  equations. 
Neural  networks  need  to  be  retrained  if  added  information  is  to  be  incorporated  into  ttem. 
Adding  information  to  a  CBR  system  only  requires  that  the  new  case  be  added  to  the  database, 
and  possibly  that  the  database  be  reindexed  (Buta,  1994).  As  mentioned  before,  reindexing  may 
only  be  necessary  at  certain  times. 

In  short,  a  CBR  system  can  present  all  cases  relevant  to  a  given  situation,  clearly  explain 
why  those  cases  are  relevant,  and  indicate  how  the  previous  cases  may  be  applied. 

Real-Worid  Case-Based  Reasoning  (CBR)  Applications 

There  have  been  several  applications  of  CBR  technology  in  areas  of  business  and 
manufacturing.  This  section  describes  some  of  these  systems  and  the  benefits  they  have  provided. 
Also  in  this  section  are  brief  descriptions  of  some  commercially  avmlable  CBR  tools. 

Large  banks  receive  up  to  2,000  telexes  every  day  describing  different  kinds  of 
transactions.  The  classification  and  routing  of  these  telexes  used  to  be  done  by  hand.  Cognitive 
Systems  was  contracted  to  automate  this  process.  Cognitive  took  one  year  to  develop  an  expert 
system  called  Prism  to  accomplish  this  task.  Cognitive  then  built  a  second  system  for  another 
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bank,  this  one  taking  only  four  months.  The  new  Prism  took  between  two  and  seven  seconds  to 
process  a  telex  and  it  achieved  an  accuracy  rate  of  72  percent. 

Cognitive  then  decided  to  build  a  CBR  version  of  the  second  system  as  an  experiment  It 
was  developed  in  two  weeks,  processed  telexes  in  0.19  to  0.25  seconds,  and  achieved  an  accur^ 
rate  of  77  percent.  The  customer  had  the  expert  system  replaced  with  the  new  case-based  version 
(Barletta,  1991). 

Another  example  pertains  to  manufacturing.  Lockheed  uses  composite  materials  such  as 
Graphite-Epoxy  to  produce  components  for  airplanes,  satellites,  and  missiles.  These  parts  must 
be  cured  in  an  autoclave  for  four  to  eight  hours.  Since  the  time  is  so  long,  Lockheed  pla^s 
several  parts  in  the  autoclave  at  one  time.  Different  parts  have  different  sizes,  shapes,  and 
composition;  thus,  they  require  different  heating  characteristics.  The  air  currents  in  the  autoclave 
produce  hot  and  cool  spots,  also  affecting  the  curing  process.  Therefore,  Lockheed  spends  much 
time  determining  how  different  parts  should  be  positioned  in  the  autoclave.  The  placement  ofthe 
parts  is  based  more  on  experience  than  knowledge  because  the  placement  process  is  not  wdl 
understood.  Rules  could  not  be  easily  developed  for  this  process,  so  Lockheed  decided  to 
develop  a  CBR  system  to  determine  the  placements.  The  system,  called  Clavier,  greatly  improved 
the  process.  As  of  August  1991,  Clavier  was  still  in  use  at  Lockheed's  Sunnyvale  Plant  (Barletta, 
1991). 


CBR  techniques  are  also  popular  in  customer  service  applications.  The  SMART  system, 
developed  by  Compaq  Computer,  is  an  integrated  call-tracking  system  that  can  diagnose  problems 
experienced  with  Compaq  products.  Before  the  system  was  used,  approximately  50  percent  of  all 
problems  were  resolved  on  the  first  call.  By  using  SM/^RT,  that  result  increased  to  87  percent. 
Compaq  estimates  that  SMART  paid  for  itself  within  a  year  (Allen,  1994). 

A  CBR  system  was  also  designed  to  rate  corporate  bonds  using  the  Standard  &  Poor's 
(S&P)  bond  rating  scheme.  Two  sets  of  data  were  generated  for  testing  purposes  with  one  of  the 
sets  being  incomplete.  The  data  in  both  of  these  sets  had  never  been  seen  by  the  CBR  system. 
After  running  the  data  through  the  system,  the  results  matched  the  S&P  recommended  ratings 
90.4  percent  ofthe  time  for  the  complete  data  set  and  84.4  percent  of  the  time  for  the  incomplete 
data  set  (Buta,  1994). 

There  are  a  few  CBR  systems  available  commercially.  One  of  these  systems  is  called  CBR 
Express  and  is  produced  by  Inference  Corporation.  CBR  Express  runs  under  Microsoft  Windows 
or  MVS. 

CBR  Express  is  a  case-based  reasoning  shell  for  developing  experience-based  knowlalge 
systems.  It  provides  three  major  capabilities:  case-based  reasoning,  natural  language  text 
retrieval,  and  an  interactive  user  interface.  Users  can  build  knowledge  bases  using  a  case  history 
approach  and  free  text  input.  Fill-in-the-blank  forms  are  used  to  facilitate  data  entry.  For 
inffumation  access,  screens  are  presented  for  describing  problems,  answering  questions  to  narrow 
each  inquiry,  listing  possible  solutions  to  resolve  every  case,  and  starting  each  new  problem 
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through  an  initial  search.  When  cases  are  authored  for  inclusion  into  the  knowledge  base,  screens 
are  presented  for  entering  and  defining  cases,  creating  appropriate  questions/answers  for  each 
case,  and  defining  effective  solutions. 
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APPENDIX  F 


ANALYSIS  OF  ISAAC  CAPABILITIES 

The  Integrated  Simulation  Assessment  of  Airbase  Capability  (ISAAC)  model  was  to  be 
the  main  component  of  the  Enhanced  Simulation  Assessment  of  Airbase  Capability  (ESCAM) 
system.  As  a  result  of  drastic  funding  reductions,  ISAAC  is  the  only  component  of  ESCAM 
system  that  is  anywhere  near  being  mature.  ISAAC  is  a  decision  support  tool  that  analyzes  the 
competing  demand  for  12  airbase  resources  required  to  launch  and  maintain  combat  sorties  of  a 
single  unit  (e.g.,  a  Tactical  Fighter  Wing).  ISAAC  is  implemented  using  a  Monte  Carlo  discrete 
event  simulation  technique.  To  perform  an  assessment  of  a  specific  unit,  ISAAC  requires  the 
following  input  data:  Operational  Flight  Tasking,  Airbase  Resources,  and  Maintenance  Task 
Networks  (MTNs).  This  data  is  defined  in  a  collection  of  many  different  files,  each  which  contain 
column-sensitive  data.  A  User  Interface  Prototype  (UIP)  was  developed  to  enable  the  user  of  the 
system  to  easily  manipulate  the  data  used  in  ISAAC,  but  to  this  point  has  only  limited  capability. 
The  current  capabilities  of  ISAAC  include:  assess  the  sortie  generation  capability  of  a  combat 
unit,  identify  operational  and  logistics  limiting  factors,  experiment  with  alternate  logistic  and 
operational  plans,  determine  required  resources,  predict  supportable  levels  of  effort,  and  evaluate 
Status  of  Resources  and  Training  (SORTS)  data.  Currently,  there  is  only  MTN  data  available  fiar 
the  F15  and  F16  aircraft. 

ISAAC  and  the  UIP  model  were  designed  to  run  on  any  80x86  processor  workstation. 
The  documentation  called  for  a  minimum  of  4  megabytes  (MB)  of  extended  memory  which  had  to 
be  configured  as  a  virtual  disk.  We  obtained  the  software  and  installed  it  on  a  80486  machine 
with  8  MB  of  extended  memory  running  MS  DOS  5.1.  According  to  the  documentation, 
VDISK.SYS  and  RAMDRIVE.SYS  were  suggested  as  the  utilities  to  create  the  ram  disk,  with 
VDISK.SYS  being  the  most  compatible  with  the  software.  We  were  unable  to  obtain  the 
VDISK.SYS  utility  so  we  implemented  the  ram  disk  using  RAMDRIVE.SYS.  We  were 
successful  in  getting  the  UIP  program  to  bring  up  the  initial  logo  screen  and  the  main  menu,  but 
we  were  unable  to  run  any  other  component  of  the  UIP.  This  could  be  a  result  of  not  having 
VDISK.SYS. 

The  Logistics  Composite  Model  (LCOM)  shares  many  similarities  with  ISAAC.  LCOMis 
designed  to  simulate  a  broad  range  of  aircraft  operations,  maintenance  functions,  supply  fimctions, 
and  scheduling  at  an  Air  Force  base.  The  LCOM  model  reads  a  LCOM  database,  which  is  a 
collection  of  1 1  different  column-sensitive  forms.  These  forms  include:  Resource  Definitions, 
Attribute  Definitions,  Task  Definitions,  Task  Network  Definitions,  Clock  Decrements,  Empirical 
Distributions,  Shift  Change  Policies,  Mission/Activity  Definitions,  Aircraft  Assignment  Search 
Patterns,  and  Sortie  Generation  Data.  We  obtained  the  F 16  database;  this  file  contained  over 
10000  lines  of  forms  and  had  very  little  documentation.  The  process  of  developing  these  forms  is 
partially  automated  but  there  still  is  a  good  deal  of  work  that  must  be  done  manually.  Programs 
exist  to  prepare  and  format  Maintenance  Data  Collection  (MDC)  system  information  into  LCOM 
forms  for  unscheduled  maintenance  tasks  only. 
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The  majority  of  the  LCOM  forms  are  contmned  in  the  Task  Network  Definitions.  The 
Task  Definitions  include  such  information  as  the  priority  and  duration  of  the  task  and  the 
resources  required  by  it.  A  delay  time  can  also  be  defined  in  the  Task  Definitions.  The  Task 
Network  Definitions  define  the  sequence  of  performing  maintenance  tasks.  There  is  great 
flexibility  in  writing  Task  Networks  but  the  logic  is  somewhat  cryptic  and  hard  to  follow. 

HQ  AFMEA  is  pursuing  development  of  a  Modem  Maintenance  Modeling  Tool.  This 
program  has  identified  needs  of  the  LCOM  community  to  develop  a  new  system  with  object- 
oriented  modeling  capabilities,  modem  graphical  user  interfaces,  and  integrated  data  importation 
and  analysis  modules.  This  tool  will  use  the  Integrated  Model  Development  Environment 
(IMDE),  which  is  a  domain-independent  Computer-Aided  Software  Engineering  (CASE)  tool  for 
the  development  of  object-oriented  discrete  event  simulations.  IMDE  is  domain  independent 
because  users  decide  what  the  objects  they  build  will  represent.  This  is  in  contrast  to  ISAAC  and 
LCOM  which  are  heavily  tied  to  the  airbase  logistics  domain.  IMDE  is  integrated  with  an  obj«:t- 
oriented  database  which  is  used  to  store  the  user-created  objects  as  well  as  many  other 
components  of  the  model. 

Models  are  constmcted  in  IMDE  by  first  constmcting  the  parts  of  the  model  which 
represent  entities  in  a  given  model.  These  parts  are  then  hooked  together  to  form  a  complete 
simulation.  The  completed  simulation  can  then  be  mn  and  the  results  can  be  analyzed  in  the  post 
processor.  Once  a  project  has  been  constmcted  in  IMDE,  it  is  easy  to  alter  the  parameters  of  the 
model  and  mn  the  new  project.  Within  IMDE,  there  is  a  concept  of  user  level  which  facilitates 
the  use  of  a  diverse  group  of  people  to  work  on  a  project. 

Both  LCOM  and  ISAAC  use  column-sensitive  ASCII  files  to  define  and  drive  the  modd. 
A  good  working  knowledge  of  either  system  is  necessary  to  look  at  these  files  and  deduM 
pertinent  information.  Within  the  IMDE  environment,  users  have  a  graphical  picture  of  the 
objects  they  create.  Someone  not  familiar  with  IMDE  could  look  at  a  graphical  representation  of 
the  objects  in  the  model  and  should  be  able  to  understand  to  some  degree  what  is  being  modeled. 
IMDE  also  allows  the  user  to  document  individual  objects  and  store  this  documentation  in  the 
database  which  facilitates  the  maintenance  of  the  models. 

Although,  we  have  never  developed  simulations  in  either  ISAAC  or  LCOM,  we  believe 
that  the  process  would  be  very  time  consuming.  We  also  believe  that  training  people  to  use  either 
ISAAC  or  LCOM  would  be  much  more  difiScult  than  training  someone  to  use  IMDE. 
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